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(54) DATA STRUCTURE OF DIGITAL MAP FILE 



(57) The present Invention provides a temriinai de- 
vice for reading a cartographic file in which updating one 
cartographic file does not require updating cartographic 
files in the neighboring units. For this purpose, carto- 
graphic files which represent respective units extracted 
by dividing a map into a plurality of areas each comprise 
node records generated for respective nodes and link 
records generated for respective links. Given node 
records contain coordinate Infonmation about neighbor- 



ing nodes which define connections of roiads between 
its unit and a neighboring unit. The cartographic files are 
stored in a first storage device (1 9). Said data process- 
ing portion (13) executes a process of searching for a 
route by using the cartographic files. During the route 
search, the data processing portion (1 3) traces the con- 
nection from a road in one unit to a road in another, 
neighboring, unlton the basis of the coordinate informa- 
tion about the neighboring nodes of said one unit and 
said neighboring another unit. 
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Description 

TECHNICAL FIELD 

[0001] The present invention reiates to tenninal de- 5 
vices, and more particularly to a temninai device for 
reading cartographic files from an Internal storage de- 
vice in which the cartographic files are stored as digital 
data generated about individual units defined by dividing 
a map into a plurality of regions. 

BACKGROUND ART 

(Rrst Baclcground Art) 

[0002] Recently, an increasing number of vehicles are 
carrying navigation systems. Early navigation systems 
were only provided with flies for generating maps on a 
screen (hereinafter referred to as cartographic files). 
However, recent models can be supplied not only with 
the cartographic files but also with traffic information and 
route guide information. Supply of such various infomna- 
tion has made the car navigation systems so convenient 
that they are expected to rapidly prevail more and more. 
[0003] The earlier navigation systems were equipped 
with storage devices having read-only storage media 
such as CD-ROMs. Cartographic files to be provided to 
users and their relevant data are previously recorded in 
the storage media. The storage devices read the carto- 
graphic files recorded In the storage media when nec- 
essary. The read cartographic files are referred to by the 
users, or used in route search or map matching process. 
[0004] Generally, in order to efficiently manage a hi- 
erarchical structure of maps on different scales, a map 
is equally divided into rectangular areas in the longitude 
and latitude directions and a digital cartographic file is 
generated for each rectangular ariea. Now, In First Bacl<- 
ground Art, such a rectangular area is called a unit. 
[0005] Such cartographic files are used in the car nav- 
igation systenns typically for the route search process or 
process of correcting the present position (map match- 
ing). The cartographic files therefore contain road net- 
work data. The road network data is at least composed 
of connection information showing connections among 
nodes and links. Generally, a node Is a piece of infor- 
mation which represents an intersection In the road net- 
work, and a link is vector information which represents 
a road between two intersections. A collection of such 
nodes and links expresses a map which shows the road 
network in each unit. 

[0006] While minimum details of the road network can 

be represented with the nodes, links and their connec- 
tion infomnation, it is not enough for the purpose of dis- 
playing a map. For example, most roads in mountain or 
seaside areas are curved between intersections. There- 
fore the road network data further contains information 
for specifying the link shape to display curved roads. As 
is clear from this, the links are often represented by vec- 



tor data. 

[0007] Further, the roads include various types, such 
as national roads, prefectural roads, etc. The roads can 
be classified also according to the number of lanes, 
whether it has a median strip, etc. The road network data 
therefore also contains attribute infomrtatlon whteh 
shows the road type and the like. 
[0008] Some Intersections have their own names and 
others donl. Further, some Intersections have traffic sig- 
nals and others don't. Therefore the road network data 
further contains attribute Information for each node. 
Each piece of the attribute information contains informa- 
tion showing the name of the intersection, presence/ab- 
sence of traffic signals, etc. 

[0009] When a road extends over a plurality of units 
In a cartographto file having the vector data structure, 
special nodes are separately generated at the boundary 
between the units (referred to as neighboring nodes 
hereinafter). The connection of road can be traced be- 
tween the neighboring units via the neighboring nodes. 
To specify the correspondence between a nelghboriiig 
node of a unit and a neighboring node of a neighboring 
unit, the conventional cartographic files contain their off- 
set addresses and record numbers. The offset address 
shows the address location of the neighboring node on 
the basis of a reference address. The record number 
shows where the neighboring node Is recorded, counted 
from the first node In the cartographic file of the neigh- 
boring unit. 

(Second Background Art) 

[0010] As has been explained in First Background Art, 
the earlier conventional navigation systems could only 
use the cartographic files recorded in read-only record- 
ing media, so that it was difficult to provide them with 
real-time information. Typical examples of such real- 
time information Include the traffic and weather informa- 
tion. A map providing system which can provide such 
real-tinne Information and the cartographic files is dis- 
closed in "Japanese Patent Laid-Open Publication No. 
7-262493". for example. In the map providing system of 
this reference, the cartographic files and real-time Infor- 
mation are downloaded from an infomnatlon providing 
center to a terminal device carried on a car through a 
communtoation medium. 

[0011] The map providing system Is constructed on 
the basis of the mobile communication technology and 
digital broadcast technology to provide infomnatlon in re- 
al time. In such a map providing system, the center sta- 
tion distributes Infomnatlon to a moving body in the serv- 
ice area by using a given broadcast channel. The center 
station is typically a communication satellite (so-called 
CS), a broadcasting satellite (so-called BS), or a ground 
wave digital broadcast station. A map providing system 
using the mobile communication technology and digital 
broadcast technology is disclosed in "Japanese Patent 
Lald-Open Publication No.7-154350", for example. 
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More specifically, this reference discloses technical con- 
tents for limiting the broadcast area for certain infomia- 
tlon. That is to say, when a center station sends multl- 
ptexed Information through a broadcast medium, it at- 
taches an area code, like a postal code, to each piece s 
of information. A tennlnal device previously records, In 
a memory, as an ID, the area code corresponding to its 
present position. In the terminal device, a data extract- 
ing circuit separates the multiplexed information sent 
from the broadcast station and extracts the area code 
attached to each piece of the Information. The extracted 
area codes are compared with the recorded ID in the 
terminal device. When the two agree, the temiinal de- 
vice allows the user to refer to the Information having 
the object area code. 

[0012] As can be seen from the description above, 
map providing systems which provide maps through 
communication or broadcast are being Intensively de- 
veloped In these years. In such a map providing system, 
a center station reads out target cartographic files by the 
unit and sends them to a temiinal device. The terminal 
device receives the cartographic data from the center 
station and stores It In the storage device. The stored 
cartographic file is used as needed, for user's reference, 
route search process, or map matching process. 

(Problems of the First Bacl<ground Art) 

[0013] In the conventional systems, as is clear from 
the description in First Background Art, a cartographic 
file of a unit contains Information which directly specifies 
the Internal data structure of cartography files in the 
neighboring units (the aforementioned offset addresses 
or record numbers). 

[0014] For example, when a new road has been con- 
structed in a unit, the cartographic file of this unit is up- 
dated, as a matter of course. In the updated cartograph- 
ic file, the positlonis of the neighboring nodes have often 
been changed. Then, In the conventional method using 
infonnation directly specifying the internal data structure 
ofthecartographicfiles, it is impossible to correctly trace 
from a neighboring node recorded in a cartographic file 
of a neighboring unit to the corresponding neighboring 
node in the updated cartographic file. That is to say, up- 
dating one cartographic file often requires updating the 
cartography files of its neighboring units. 
[0015] i\^easures for evaluating the quality of the 
aforementioned digital cartographic files include the de- 
gree to which they give the details of the map. However, 
since the links are represented by vector data in the car- 
tographic files, representing a more detailed map In- 
creases the amount of data of the cartographic file. 
[0016] Such cartographic files have conventionally 
been used mainly In the car navigation systems. In the 
car navigation systems, the cartographic files are re- 
corded in large-capacity storage media such as CD- 
ROMs, DVD-ROMs, hard disks, etc. However, in the fu- 
ture, the cartographic files will be used not only in the 



car navigation systems but also in portable Information 
devices. It Is difficult to equip such portable information 
devices with such large-capacity storage media as are 
used in the car navigation systems. In this respect, there 
is an intensive demand for compression of the amount 
of data of the cartographic files. 

(Problems of the Second Background Art) 

[0017] By the way, the references cited in Second 
Background Art do not disclose how the terminal devtoe 
stores the cartographic files In the storage device. A like- 
ly method is that the terminal device generates a carto- 
graphic file for each unit received and stores the gener- 
ated cartographic files in the storage device. However, 
this method is disadvantageous In that the storage re- 
gion cannot be efficiently used. For example, as shown 
in Fig. 71 , suppose that a map p representing an area Is 
sectioned into 64 rectangular units. Also suppose that 
the terminal device receives four units 71 to 74 and 
stores them. As Is well known, the storage region in the 
storage device is managed in clusters; where the data 
size of each unit does not always agree with an Integral 
multiple of the cluster size. Therefore, when the terminal 
device generates four files 81 to 84 for the received four 
units 71 to 74, then, as shown in Fig. 72, some areas will 
be possibly left unused in the four clusters 91 to 94. In 
Fig. 72, the dotted parts are regions where the files 81 
to 84 have been recordeld. The hatched parts show the 
vacant areas. The vacant areas left in the clusters 91 to 
94 are not used. That it to say, even when the temrilnal 
device receives a unit 75 other than the units 71 to 74 
(see Fig.71), the file generated on the basis of this unit 
75 is not stored in the vacant areas in the clusters 91 to 
94. As is clear from this, a larger number of clusters will 
be left not completely filled as the temrilnal device re- 
ceives a larger number of units. That is, the efficiency 
of use of the storage region Is lowered. 
[0018] When the map Is divided Into a relatively small 
number of units, the clusters will be less likely to be left 
partly unfilled. For example, suppose that the map ^cov- 
ering the area of Fig.71 is sectioned into 1 6 rectangular 
units as shown in Fig.73. The area represented by the 
unit 76 of Flg.73 corresponds to the area covered by the 
units 71 to 74 In Flg.71 . Also suppose that the terminal 
device receives and stores one unit 76. Under this as- 
sumption, when the terminal device generates one file 
86 for the one unit 76, then a vacant area is left only in 
one cluster 96 as shown In Flg.74. The dotted part in 
Rg.74 shows the area where the file 86 has been re- 
corded. The hatched part shows the vacant area. 
[0019] As is clearfrom this, when the map is sectioned 
into smaller units (see Fig.71 ) and cartographic files rep- 
resenting a certain area are stored In the storage device, 
then relatively large vacant areas are formed in the stor- 
age device (see Fig.72). However, when the map is sec- 
tioned into larger unite (see Fig.73), a smaller vacant 
area is left even when the cartographic data covering 
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the same area is stored In the storage device (see Fig. 
74). That is to say, considering the effective use of the 
storage region, It Is desirable to section the map Into a 
less number of units. 

[0020] However, sectioning the map into a less s 
number of units means a larger amount of data in each 
unit. Therefore the base station must transmit a larger 
amount of data at one time to the terminal device. As a 
result the wireless transmission path will become more 
susceptible to congestion; that Is, this causes another 
problem that the wireless transmission path cannot be 
used efficiently. That is to say, while giving priority to the 
effective use of the storage region reduces the efficiency 
of use of the wireless transmission path, giving priority 
to the effective use of the wireless transmission path re- 
duces the efficiency of use of the storage region. 
[0021] Accordingly, a first object of the present Inven- 
tion Is to provide a data structure of the cartographic files 
in which updating one cartographic file does not require 
updating cartographic files of the neighboring units. A 
second object of the present Invention Is to provide a 
data structure of the cartographic files in which the 
amount of data can be compressed. A third object of the 
invention is to provide a map providing system which 
can efficiently use the storage region of the terminal de- 
vice and can also efficiently use the transmission path 
between the center station and the terminal device. 

DISCLOSURE OF THE INVENTION 

[0022] An aspect of the Invention Is directed to a ter- 
minal device for reading a cartographic file from a stor- 
age device In which cartographic files are stored as dig- 
ital data generated for individual units fonned by dividing 
a map into a plurality of areas, 

wherein each unit contains a road network repre- 
sented by nodes and links, and each cartographic 
file comprises node records generated for respec- 
tive nodes and jink records generated for respective 
links, and 

the node records each contain infomnation about a 
non-neighboring node representing an intersection 
on the road network or infomnation about a neigh- 
boring node defining a connection of roads between 
its unit and another unit adjoining the unit, 
the infomnation about the neighboring node being 
coordinate information about the neighboring node, 
and wherein the temnlnal device comprises, 
an input device responsive to an operation by a us- 
er, for generating information specifying a map ar- 
ea, 

a data processing portion for specifying a record re- 
gion where a necessary cartographic file is stored 
on the basis of the infomnation generated by the in- 
put device, and 

a read control portion for reading the cartographic 
file from the storage device on the basis of the 



record region specified by the data processing por- 
tion, 

and wherein the data processing portion performs 
a given process by using the node records and the 
link records recorded in the cartographic file read 
by the read control portion, and 
the data processing portion traces a connection 
from a road in one unit to a road In another, neigh- 
boring unit on the basis of the coordinate infomna- 
tion about the neighboring nodes of said one unit 
and said neighboring another unit. 

[0023] According to the aspect above, during route 
search, the data processing portion traces the connec- 
tion of road extending from one unit Into a neighboring 
unit on the basis of coordinate Infomnation about the 
neighboring nodes of the unit and the neighboring unit. 
In this way, the data processing portion can trace the 
connection of road between two units without referring 
to information which directly specifies the internal data 
structure In the cartographic files. Accordingly, when a 
cartographic file of a unit in the storage device has been 
updated, it is not necessaiy to update cartographic files 
of the neighboring units. 

[0024] Another aspect is directed to a terminal device 
for reading a cartographic file from a storage device in 
which cartographic files are stored as digital data gen- 
erated for individual units formed by dividing a map into 
a plurality of areas, 

wherein each cartographic file stored in the storage 
device is provided with a file name uniquely corre- 
sponding to the map area represented by itself, and 
the tenninal device comprises, 
an Input device responsive to an operation by a us- 
er, for generating infomiation specifying a map ar- 
ea, 

a data processing portion for specifying a record re- 
gion where a necessary cartographic file is record- 
ed on the basis of the infonmatlon generated by the 
input devtee, and 

a read control portion for reading the cartographic 
file from the storage device on the basis of the 
record region specified by the data processing por- 
tion. 

[0025] According to the aspect above, each carto- 
graphic file is provided with a file name which uniquely 
specifies the map area it represents. This allows the da- 
ta processing portion to identify neighboring cartograph- 
ic files from their names. In this way, according to this 
aspect, it is not necessary to record any information 
which is related to the data structure of cartographic files 
of the neighboring units, so that the plurality of carto- 
graphic files are remotely related. Therefore, updating 
one cartographic file does not require updating other 
cartographic files. 

[0026] Af urther aspect is directed to a temninal device 
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for reading a cartographic fiie from a storage device In 
which cartographic files are stored as digital data gen- 
erated for individual units fonned by dividing a nnap Into 
a plurality of areas, 

wherein each unit contains a background which Is 
divided into objects each capable of being drawn 
with one strolce, and the plurality of objects are 
grouped so that ones having the sanne attribute are 
contained in the same group, and 
the cartographic file contains background records 
in which infomnation about the objects is recorded 
for each group, 

and wherein thetemiinal device comprises, 
an input device responsive to an operation by a us- 
er, for generating Information specifying a map ar- 
ea, 

a data processing portion for specifying a record re- 
gion where a necessary cartographic file Is stored 
on the basis of the infomriatlon generated by the in- 
put device, 

a read control portion for reading the cartographic 
fiie from the storage device on the basis of the 
record region specified by the data processing por- 
tion, and 
an output device, 

and wherein the data processing portion causes the 
output device to display the background on the ba- 
sis of the background records contained in the car- 
tographic file read by the read control portion. 

[0027] According to the aspect above, In a carto- 
graphic file, objects having the same attribute are re- 
corded together in the same background record, which 
eliminates the need to redundantly record the infomna- 
tionaboutthe attribute and thus enables reduction in the 
amount of data in each cartographic file. 
[0028] Another aspect is directed to a terminal device 
for reading a cartographic file from a storage device in 
which cartographic files are stored as digital data gen- 
erated for individual units fornied by dividing a plurality 
of maps on different scales each into a plurality of areas, 

wherein the plurality of cartographic files have a hi- 
erarchical structure based on the scales, each unit 
contains a road network represented by nodes and 
links, and each cartographic file at least contains 
node records whk^h are generated for respective 
nodes and contain coordinate information about the 
nodes, and link records which are generated for re- 
spective links, and 

in each cartographic file, the node records are re- 
corded in an ascending or descending order of the 
coordinate information about the nodes, 
and wherein the terminal device comprises, 
an input device for generating information specify- 
ing a map area, 

a data processing portion for specifying a record re- 



gion where a necessary cartographic file Is record- 
ed, on the basis of the information generated by the 
input device, and 

a read control portion for reading the cartographic 
5 file from the storage device on the basis of the 
record region specified by the data processing por- 
tion, 

and wherein the data processing portion searches 
for a node in a unit at a higher level which corre- 
10 sponds to a node contained in a unit at a lower level 
on the basis of the coordinate Information recorded 
in the cartography file read by the read control por- 
tion. 

[0029] According to the aspect above, the data 
processing portion retrieves a node In a higher-level unit 
which corresponds to a node contained in a lower-level 
unit on the basis of the node coordinate information, I. 
e. the coordinate Information recorded in the carto- 

20 graphicflle read by the read control portion. In this way, 
the data processing portion can trace nodes having the 
same coordinates between different levels without the 
need to refer to any information which directly specifies 
the internal data structure in the cartographic files. 

25 Therefore, updating a cartographic fiie of a unit con- 
tained in the storage device does not require updating 
the cartographic files of the neighboring units. 
[0030] A further aspect is directed to a system in 
which a center station provides a cartographic file to a 

30 terminal device through a transmission path, 

wherein the center station comprises, 
a first storage devtoe containing the cartographic 
file, the cartographic -file representing a map of a 
35 predetermined area, 

a read control portion for reading, as cartographic 
data, part or all of the cartographic file from the first 
storage devtee^ 

a packet assembler for assembling packets in a 
40 fonm appropriate for the transmission path by using 
the cartographic data read by the read control por- 
tion, and 

a transnriitting portion for transmitting the packets 
assembled by the packet assembler to the tenmlnal 
45 device through the transmission path, 

and wherein the terminal device comprises, 
a receiving portion for receiving the packets trans- 
mitted by the transmitting portion through the trans- 
mission path, 

so a data processing portion for disassembling the 
packets received by the receiving portion and re- 
storing the cartographic data, and 
a second storage device having.an internal storage 
medium for storing a cartographic file, 

55 wherein when a cartographic file related to the car- 
tographic data restored this time is already stored 
in the second storage device, the data processing 
portion reads that cartographic file from the second 
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storage device, 

and the data processing portion perfonns the proc- 
ess of adding the restored cartographic data to the 
second cartographic file thus read and storing the 
cartographic file in the second storage device. s 

[0031] According to the aspect above, the data 
processing portion combines together the currently re- 
stored cartographic data and the cartographic file read 
from the second storage device and stores It into the io 
second storage device, thereby updating the carto- 
graphic file. In this way, the data processing portion gen- 
erates a cartographic file not only on the basis of the 
cartographic data received at the receiving portion. The 
data processing portion adds the currently received car- is 
tographic data to the currently read cartographic file. 
Thus the second storage device stores not a targe 
number of cartographic files containing small amounts 
of data but cartographic files containing substantial 
amounts of data, which prevents formation of vacant ar- 
eas in the clusters. This realizes a map providing system 
which can effectively utilize the storage region in the ter- 
minal device. 

[0032] Furthermore, according to the aspect above, 
even if the center station transmits small-sized carto- 25 
graphic data, the terminal device organizes the carto- 
graphic data from the center station into one file to sup- 
press formation of vacant areas in the clusters. In this 
way, since the center station can send small-sized car- 
tographic data, the transmission path Is less apt to be 30 
congested. This realizes a map providing system which 
can efficiently utilize the transmission path. 

BRIEF DESCRIPTION OF THE DRAWINGS 

33 

[0033] 

Fig.1 is a block diagram showing the structure of a 
map providing system according to a first embodi- 
ment of the present invention; 4o 
Fig. 2 Is a diagram used to explain the hierarchical 
structure of maps-represented by a first cartograph- 
ic file 111 and a second cartographic file 25 shown 
inFig.1; 

Fig.3 Is a diagram used to explain a unit at the 45 
highest level (level "3") shown in Fig.2; 
Fig.4 is a diagram used to explain the parent-child 
relation between the levels "3" to "0"; 
Fig.5 is a diagram showing a tree structure for man- 
aging the first cartographic file 1 1 1 and the second so 
cartographic file 25; 

Fig.6 is a diagram showing the data structure of one 
unit U belonging to a certain level; 
Fig7 is a diagram showing the data structure of a 
cartographic file OF; 55 
Fig.8 schematically shows maps which are repre- 
sented by background data; 
Flg.9 Is a diagram showing rendered objects B01 



and B02, which is used to explain the concept of 
the rendered objects; 

Fig. 10 is a diagram showing the detailed data struc- 
ture of a background data table; 
Fig. 11 is a diagram showing graphic data composed 
of eight element points PO to P7; 
Flg.12 Is a diagram showing the data structure In 
which the absolute coordinates of PO to P7 of Fig. 
11 are described in an object record OR; 
Fig.13 Is a diagram showing the graphic data of Fig. 
11, where the element points PO to P7 are repre- 
sented by the relative coordinates; 
Fig. 14 is a diagram showing the data structure in 
which the relative coordinates of the element points 
PO to P7 of Fig. 1 3 are described in the object record 
OR; 

Flg.15 Is a diagram showing an object OBJ com- 
posed of element points PO, PI and Pn; 
Fig.1 6 is a diagram showing supplementary ele- 
ment points P2 and P3 set on the straight line con- 
necting the element points P1 and Pn of Flg.15; 
Fig.1 7 is a diagram showing the data structure In 
which the relative coordinate infomnation about the 
element points PO, PI, P2, P3 and Pn of Fig.1 6 Is 
recorded in the object record OR; 
Fig.1 8 is a diagram showing the data structure of 
the object record OR in which the element points 
PO and Pn of Fig. 15 are represented by their abso- 
lute coordinates and the element point P1 Is repre- 
sented by its relative coordinates; 
Fig. 1 9 is a diagram showing a rendered object D03 , 
which is used to explain an example in which the 
relative coordinates are not applied to the boundary 
between the objects; 

Fig.20 is a diagram showing the data structure of a 
string of coordinates about the rendered object 
D03, where the relative coordinates are not applied 
to the boundary between the objects; 
Fig.21 Is a diagram showing the rendered object 
D03, which is used to explain the relative coordi- 
nates applied to the boundary between the objects; 
Fig.22 is a diagram showing the data structure of a 
string of coordinates about the rendered object 
D03, where the relative coordinates are applied to 
the boundary between the objects; 
Flg.23 Is a diagram used to explain the relation be- 
tween a basic character/symbol table and a detailed 
character/symbol table; 

Fig.24 is a diagram showing the detailed data struc- 
ture of the character/symbol table; 
Fig.25 Is a diagram used to explain the relation be- 
tween first road network data and second road net- 
work data; 

Fig.26 is a diagram used to explain the concept of 
nodes and links; 

Flg.27 is a diagram showing the detailed data struc- 
ture of a first node table; 

Fig.28 is a diagram showing an order in which the 
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node records NR1 to NR11 about the nodes NO to 
N10 of Fig.26 are arranged; 
Fig.29 Is a diagram used to explain a normalized 
coordinate system which is a method for represent- 
ing the coordinates of nodes in the longitude and s 
latitude directions; 

Fig.30 Is a diagram showing the detailed data struc- 
ture of a first link table; 

Flg.31 Is a diagram used to explain link connection 
infomnation recorded In each link record LR; io 
Ftg.32 is a diagram used to explain a process In 
which the connection of road network is traced on 
the basis of node connection Infomiation and the 
link connection infomriation; 
Fig.33 is a diagram showing the concept of route 
search performed in the terminal device 1 ; 
Flg.34 is a flowchart showing the procedure of bidi- 
rectional interlevel search performed in the temnlnat 
device 1 ; 

Fig.35 Is a flowchart showing the detailed proce- 20 
dure of the step of Fig. 35 for reading a cartographic 
file CF(step S103); 

Fig.36 is a diagram used to explain how new repre- 
sentative points are positioned to determine neigh- 
boring units NU; 25 
Fig.37 is a diagram showing a road network which 
is formed with four neighboring units U1 to U4 ad- 
joining each other; 

Flg.38 is a flowchart showing the procedure in 
which a data processing portion 13 traces the con- 30 
nectlon of road network over the boundary between 
two units U; 

Fig.39 is a diagram showing an order in which the 
node records NR of neighboring nodes are record- 
ed; 35 
Fig.40 Is a diagram used to explain a problem which 
would be encountered during a process In which 
nodes N are associated with each other between 
lower-level and higher-level cartographic files CP; 
Fig.41 is a diagram used to explain the correspond- 40 
ence betweeh the nodes N in the lower-level and 
the higher-level cartographic files CF; 
.Flg.42 Is a diagram used to explain a method for 
searching, from a node Nd in a child unit CU» for a 
node having the corresponding coordinates In a 
parent unit PU, on the basls of the normalized co- 
ordinates and the order In which the node records 
NR are recorded; 

Fig.43 is a diagram used to explain the process in 
which the terminal device 1 requests transmission so 
of a cartographic file CF; 

Fig.44 is a flowchart showing the procedure which 
the center station 2 executes after receiving a re- 
quest REQ; 

Fig.45 is a diagram showing the structure of data 55 
generated during the process of assembling pack- 
ets P from the cartographic file CF; 
Flg.46 is a flowchart showing the detailed proce- 



dure of step S504; 

Fig.47 is a diagram showing the detailed Internal 
data stmcture of master data MD; 
Fig.48 is a flowchart showing the procedure in 
which the tenmlnal device 1 receives a cartographic 
file CF; 

Fig.49 Is a flowchart showing the detailed proce- 
dure of the step S703 of Fig.48; 
Fig.50 is a diagram showing the structure of data 
generated during the process of generating a car- 
tographic file CF from the packets P11, P12... 
P1j... Pij; 

Flg.51 is a flowchart showing the detailed proce- 
dure of the step S704 of Fig.48; 
Flg.52 is a block diagram showing the structure of 
a map providing system according to a second em- 
bodiment of the invention; 

Flg.53 Is a diagram showing the structure of each 
cartographic file CF stored in a first storage device 
1013 shown in Fig. 52; 

Fig.54 is a diagram showing the detailed structure 
of each unit record UR shown in Fig.53(b); 
Fig.55 is a diagram used to explain background da- 
ta BD shown in Fig.54; 

Fig. 56 is a diagram used to explain character/sym- 
bol data CD shown in Fig.54; 
Fig.57 is a diagram used to explain road network 
data ND shown in Flg.54; 

Fig.58 is a diagram showing a map displayed by su- 
perimposing basic background table data BBD, ba- 
sic character/symbol data table BCD and highway 
network data table MND shown in Fig.54, and a map 
displayed by superimposing detailed background 
table data DBD; detailed character/symbol data ta- 
ble DCD and street network data table SND shown 
in Fig.54; 

Fig.59 is a flowchart showing a procedure per- 
formed by a center station 101 shown in Fig.52; 
Fig.60 is a diagram showing the structure of data 
generated during the process in which the center 
station 101 shown in Flg.52 generates packets P 
from a cartographic file CF; 
Fig.61 is a flowchart showing the detailed proce- 
dure contained In the step SI 003 shown in Fig.59; 
Fig. 62 is a diagram showing the detailed structure 
of master data MD shown In Fig. 60(b); 
Fig. 63 is a flowchart showing a procedure per- 
fonmed by tennlnal device 102 shown In Fig.52; 
Fig. 64 is a flowchart showing the detailed proce- 
dure of the step SI 203 of Rg.63; 
Fig.65 is a diagram showing the structure of data 
generated during the process In which the terminal 
device 102 shown in Flg.52 generates a carto- 
graphic file CF from the packets P; 
Fig. 66 Is a flowchart showing the detailed proce- 
dure contained in the step SI 204 shown in Flg.63; 
Fig.67 Is a diagram showing the structure of carto- 
graphk: file CF ishown in Fig.52; 
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Fig.68 is a diagram showing the process which the 
file management portion 1 025 performs in the step 
SI 406 of Flg.66 when the first and second unit IDs 
do not agree; 

Flg.69 is a diagram showing the structure of a car- 
tographic file CP which is formed when the basic 
baclcground data table BBD, basic character/sym- 
bol data table BCD and highway networic data table 
MND shown in Fig.54 are already provided in the 
terminal device 1 02 in the step S1 204; 
Fig.70 is a diagram showing a process the file man- 
aging portion 1025 executes in the step S1406 of 
Fig.66 when the first and second unit IDs agree with 
each other; 

Fig.71 Is a diagram showing a map pwhich covers 
a certain area divided into 64 rectangular units; 
Ftg.72 is a diagram showing four clusters 91 to 94 
having vacant areas in the storage device of the ter- 
minal device; 

Fig.73 is a diagram showing the map p covering a 
certain area divided into 16 rectangular units; and 
Fig.74 is a diagram showing one cluster 96 having 
a vacant area in the storage device of the terminal 
device, which is used to explain that the efficiency 
of use of the wireless transmission path is deterio- 
rated In such a case. 

BEST iVIODE FOR CARRYING OUT THE INVENTION 

(First Embodiment) 

(System Structure) 

[0034] Fig.1 is a block diagram showing the stmcture 
of a map providing system according to an embodiment 
of the present invention. In Flg,1 .this map providlngsys- 
tem includes a terminal device 1 and a center station 2. 
The terminal device 1 and the center station 2 are con- 
nected through a communication network 3 to allow bi- 
directional communication. More specifically, an uplink 
UL and a downlink DL are extended between the termi- 
nal device 1 and the center station 2, The uplink UL is 
a communication path from the tenminal device 1 to the 
center station 2 and the downlink DL is a communication 
path from the center station 2 to the terminal device 1 . 
Typical examples of the communication network 3 In- 
clude communication networks for mobile devices like 
mobile phones, public networks such as ISDN (Integrat- 
ed Services Digital Network) and private networks. The 
communication network 3 may be composed of two or 
more of the mobile communication network, public and 
private networks. 

[0035] Next, the structure of the terminal device 1 Is 
described. The terminal device 1 is typically a car navi- 
gation system, which comprises an Input device 11 , a 
position detecting device 12, a data processing portion 
13, a request generating portion 14, a first transmit/re- 
ceive portion 15, an antenna 16, a packet disassembler 



1 7, a read/write control portion 1 8, a first storage device 
19, and an output device 110. 

[0036] The input device 11 can be realized as hard- 
ware like a remote controller for remotely controiiing the 

5 car navigation system or keys arranged on the body of 
the car navigation system, or it may be realized as soft- 
ware like buttons displayed on a menu screen of the car 
navigation system. The Input device 1 1 may be realized 
by utilizing speech recognition techniques. A user of the 

10 terminal device 1 operates the input device 1 1 to make 
various {requests to the tennlnal device 1 , e.g. to scroll 
the displayed map, change the scale, search for a route, 
retrieve information, or make connection to the center 
station 2. For its characteristic operation, the input de- 

15 vice 11 outputs to the data processing portion 13 Infor- 
mation for specifying a cartographic file OF which the 
user requires. 

[0037] The position detecting device 12 Is realized 
with a speed sensor, a gyro sensor, or a GPS (Global 

20 Positioning System) antenna and receiver. The position 
detecting device 12 may be realized by using a combi- 
nation of two or more of the speed sensor, gyro sensor 
and antenna and receiver of GPS (Global Positioning 
System). The position detecting device 12 detects the 

25 moving speed of the terminal device 1 with the speed 
sensor and then calculates the traveled distance on the 
basis of the detection; or it detects, by using the gyro 
sensor, the direction in which the terminal device 1 is 
moving, or it receives, with the antenna and receiver, 

30 electric waves from an artificial satellite to detect the ab- 
solute position of the terminal device 1 on the earth. The 
position detecting device 12 detects the present position 
of the terminal device 1 on the basis of the detected re- 
sults. 

35 [0038] The data processing portion 1 3 processes var- 
ious data as will be described later. For example, on the 
basis of information provided from the input device 11 , 
the data processing portion 13 finds the coordinates 
which specify the area of a map requested from the user 

40 and outputs it to the request generating portion 14. 
[0039] In response to the input coordinate infonna- 
tion, the request generating portion 14 generates a con- 
trol command for requesting the center station 2 to 
transmit the cartographic file CF the user requires. The 

^ generated control command Is hereinafter referred to as 
a request REQ. The request REQ has a predetemrilned 
format, which at least includes the coordinate informa- 
tion inputted to the request generating portion 14. Such 
a request REQ is outputted to the first transmit/receive 

so portion 15. 

[0040] The first transmit^recelve portion 1 5 Is typteally 
realized with a mobile communication device such as a 
mobile phone. The first transmit/receive portion 15 
sends out the input request REQ onto the uplink UL 

55 through the antenna 1 6. 

[0041 ] The request REQ is received at the center sta- 
tion 2 through the uplink UL. The center station 2 ana- 
lyzes the request REQ to specify the cartographic file 
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CR the user requires. The center station 2 retrieves the 
specified cartographic file CF from the second storage 
device 24 and assembles a plurality of packets P. The 
assembled packets P are sequentially transmitted to the 
tenminal device 1 through the communication network 3 s 
(downlink DL). Operations of the center station 2 will be 
described in detail later. In thetenninai device 1 , thefirst 
transmit/receive portion 15 receives the packets P 
through the antenna 1 6 and outputs them to the packet 
disassembler 17. The packet disassembler 17 disas- 
sembles the input packets P Into the original cartograph- 
icfile CF and outputs it to the data processing portion 1 3. 
[0042] Receiving the Input cartographic file CF, the 
data processing portion 13 perfomns predetemnined op- 
erations; when a given condition Is satisfied, it generates 
a first database 1 1 1 on the basis of the input cartograph- 
ic file CF and outputs It to the read/write control portion 
1 8. The read/write control portion 1 8 writes the Input car- 
tographic file CF into the first storage device 19, or re- 
writes an existing cartographic file CF with it. 
The series of writing operations will be described later. 
[0043] The first storage device 19 is typically coni- 
posed of a storage device which is capable of rewriting 
data, such as a hard disk drive or a flash memory. The 
first database 1 1 1 Is stored In the first storage device 1 9. 
The first database 111 is a group of data which contains 
at least one cartographic file CF which allows this ter- 
minal device 1 to function as a navigation system. 
[0044] The output device 1 1 0 is typically composed of 
a display and a speaker. The display displays the map 
represented by the cartographic file CF together with the 
present position, or displays the result of route search 
or route guide perfomned by the data processing portion 
13. The speaker provides the u&er through speech with 
the result of route guide processed by the data process- 
ing portion 13. 

[0045] The data processing portion 13 performs vari- 
ous operations by using the cartographic files CF in the 
first database 111. For example, the data processing 
portion 13 executes a process of displaying the present 
position of the temnlnal device 1 . In this case, the data 
processing portion 13 requires a map representing the 
vicinity of the present position detected by the position 
detecting device 12; in cooperation with the readAvrite 
control portion 18, it searches the first database 111 and 
extracts a cartographic file CF representing the map. 
The data processing portion 13 also performs a process 
of correcting the position, such as map matching, by us- 
ing the retrieved cartographic file CF. After the position 
correcting operation, the data processing portion 13 su- 
perimposes a pointer visually showing the detected 
present position on the map represented by the re- 
trieved cartographic file CF and outputs it to the output 
device 110. 

[0046] For example, when the user of the terminal de- 
vice 1 requests a route search, etc., through the input 
device 11, the data processing portion 13 has to read, 
for the route search, etc., cartographic files CF repre- 



senting maps showing the vicinities of the starting point 
and the destination point and cartographic files CF rep- 
resenting maps which contain the route to be searched 
for. Also in this case, the data processing portion 13 co- 
operates with the read/write control portion 1 8 to search 
the first database 111 and take out the cartographic files 
CF required for the route search, etc. The series of op- 
erations for reading the cartographic files CF will be de- 
scribed later. 

[0047] Next, the structure of the center station 2 Is de- 
scribed. The center station 2 comprises a second trans- 
mit/receive portion 21 , a received request analyzing por- 
tion 22, a read control portion 23, a second storage de- 
vice 24, and a packet assembler 25. 
[0048] As already explained, the request REQ gener- 
ated In thetenninat device 1 is transmitted to the center 
station 2 through the communication networtc 3 (uplink 
UL). The second transmit/receive portion 21 Is typbally 
composed of a communication device such as a mo- 
dem, terminal adapter, or gateway. The gateway means 
not only a device or function for Interconnecting the cent- 
er station 2 and the communication network 3 using dif- 
ferent communication protocols but it also means a de- 
vice or function for preventing illegal access to the cent- 
er station 2 from other stations. The second transmit/ 
receive portion 21 is connected to the communication 
network 3 to control the data reception from the terminal 
device 1 and the data transmission to the terrriinal de- 
vice 1. More specifically, for example, the first data 
transmit/receh/e portion 15 receives the request REQ 
transmitted through the uplink UL and outputs it to the 
received request analyzing portion 22. 
[0049] The received request analyzing portion 22 an- 
alyzes the Input request REQ and outputs the -analyzed 
result to the read control portion 23. The read control 
portion 23 reads out the cartographic file CF the terminal 
device 1 requires from the second storage device 24 on 
the basis of the input analyzed result. The second stor- 
age device 24 is typically composed of a hard disk drive, 
CD-ROM drive or DVD-ROM drive; It Is composed of a 
storage medium at least capable of reading the stored 
data and its driver. The second storage device 24 con- 
tains a second database 25. The second database 25 
is a group of data containing at least one cartographto 
file CF which allows the center station 2 to function as 
a station which provides maps to the temilnal device 1 . 
That it to say, the cartographic file CF Is digital data rep- 
resenting a map which can be provided to the terminal 
device 1 . The first database 111 in the terminal device 
1 is generated from the cartographic files CF provided 
from the center station 2. The read control portion 23 
may read out the entirety of the cartographic file CF or 
part of the cartographic file CF. The read control portion 
23 outputs the cartographic f lie CF to the packet assem- 
bler 25. The packet assembler 25 assembles packets P 
on the basis of the input cartographic file CF and outputs 
them to the second transmit/receive portion 21. The 
third transmit/receive portion 21 transmits the input 
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packets P to the terminal device 1 through the downllnic 
DL. 

[0050] The entire structure of the map providing sys- 
tem of this embodiment and the structure of the terminal 
device 1 and center station 2 have been described. 
Next, the hierarchical structure of the above-described 
cartographic files CF and the file names are described 
in detail. 

<IHierarchical Structure and File Names> 

[0051] Fig.2 is a diagram used to explain the hierar- 
chical structure of maps represented by the cartograph- 
ic files CF of this embodiment. As shown in Fig.2, first, 
a plurality of kinds of maps on different scales are pre- 
pared. In this embodiment, for convenience of explana- 
tion, it Is assumed that maps on four scaling levels are 
prepared, in the description below, the largest scale Is 
referred to as level 0, the second largest scale as level 
"1", the third largest scale as level "2", and the smallest 
scale as level "3". As is thus clear, the cartographic data 
is composed of the four levels, levels "0" to "3", the level 
"0" being the largest scale. Further, a map at a higher 
ievei is referred to as a higher-level map and one at a 
lower level is referred to as a lower-level map. As shown 
in Flg.2, a map at a higher level shows a larger area in 
less detail. On the other hand, a map at a lower level 
shows a smaller area in more detail. Maps at each level 
are sectioned at equal Intervals in the longitude and lat- 
itude directions. 

[0052] Fig.3 is a diagram used to explain units at the 
highest level (level "3"). The world map of Fig.3 is sec- 
tioned at intervals of 5 degrees 20 minutes in the latitude 
direction on the basis of latitude 0 degree. This world 
map is also sectioned at equal intervals of about 8 de- 
grees In the longitude direction on the basis of longitude 
0 degree. As a result, the world map is divided into rec- 
tangular areas about 640 kilometers square. At the high- 
est level (level "3"), the rectangular area about 640 kil- 
ometers square is referred to as a unit. At the level "3", 
digital data is generated on the basis of such a unit about 
640 kilometers square to form one cartographic file CF. 
A unit U3 (the hatched part) is now explained as an ex- 
ample of such a highest-level (level "3") unit. The high- 
est-level (level "3") unit U3 is a unit which contains KAN- 
SAI area of Japan; counted from the origin at latitude 0 
degree and longitude 0 degree, it is the 1 6th in the east 
longitude direction and 6th in the north latitude direction 
(notethatthe unit containing the origin is numbered 0th). 
This unit U3 is shown at the top of Fig.2. 
[0053] As shown in Fig.2, the map of the unit U3 is 
sectioned at intervals of 40 minutes in the latitude direc- 
tion on the basis of one corner, as shown by the dotted 
lines. The map of the unit U3 is further sectioned in the 
longitude direction at intervals of 1 degree on the basis 
of the same corner, as shown by the dotted lines. As a 
result, the map of the unit U3 is divided into 64 rectan- 
gular areas about 80 kilometers square. One unit at the 



level immediately below (i.e. the level "2") corresponds 
to a map which shows greater details of one of the rec- 
tangular areas about 80 kilometer square. The unit Ug 
(the hatched part) is explained as an example of a unit 
5 at the level "2". Counted from the origin at one corner of 
the unit U3 (for convenience, the lower left corner), this 
unit U2 is the 4th in the east longitude direction and the 
first in the north latitude direction (note that the unit 
which contains the origin is numbered 0th). This level- 
to "2" unit U2 is shown as the second one from the top of 
Rg.2. 

[0054] Similarly, the map of the unit is sectioned at 
intervals of 5 minutes in the latitude direction on the ba- 
sis of one corner and also sectioned at intervals of 7 

IS minutes 30 seconds in the longitude direction, and as a 
result the map is divided into 64 rectangular areas about 
10 kilometers square. One unit at the level Immediately 
below (I.e. the level "1 ") corresponds to a map showing 
greater details of one of the rectangular areas about 10 

20 kilometers square. For example, counted from the origin 
at the lower left comer of the unit U2, the unit (the 
hatched part) Is the 5th In the east longitude direction 
and the 3rd in the north latitude direction (note that the 
unit containing the origin is numbered 0th). This level- 

25 "1" unit U.| is shown as the third one from the top of Fig.2. 
[0055] Similarly, the map of the unit Is sectioned 
Into 64 rectangular areas about 1 .2 kilometers square. 
One unit U at the level immediately below (i.e. the level 
"1") corresponds to a map showing greater details of 

30 one of the rectangular areas about 1.2 kilometers 
square. For example, counted from the origin at the low- 
er left corner of the unit Ui , the unit Uq (the hatched part) 
is the 2nd in the east longitude direction and the 1st In 
the north latitude direction (notethatthe unit containing 

35 the origin is numbered 0th). This levero" unit Uq is 
shown as the fourth one from the top of Fig.2. 
[0056] Fig.4 is a diagram used to explain parent-child 
relation among the units U at the levels "3" to "0". Firist, 
in the description below, child units CU mean all units at 

40 lower levels which are contained in the area covered by 
one unit U . In other words, the child units CU are a group 
of units U which represent parts of the map represented 
by one unit U at a higher level. At the same time, parent 
units PU mean all units at higher levels which contain 

45 the area covered by a unit U. In other words, the parent 
units PU are a group of units U which contain, as part 
of their maps, the map represented by one unit U at a 
lower level. 

[0057] Now, the unit U3 of Fig.4, which corresponds 
so to the unit U3 shown in Fig.2, is one of the units at the 
level "3". The 64 units U formed by dividing the unit U3 
at eight equal intervals in the longitude and latitude di- 
rections are the levet-"2" units U associated with their 
parent unit PU3; i.e. they are the child units CU of the 
S5 unit U3 which belong to the level "2". 

[0058] In this way, one parent unit PU has 64 child 
units CU at the level immediately below. Each child unit 
CU Is provided with a position code. The position code 
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is Infomnation which specifies to which part of the parent 
unit PU the map of the child unit CU corresponds. In 
other words, the position code is infomnation which 
specifies the position of the child unit CU on the basis 
of Its parent unit PU. s 
[0059] Now, suppose that the parent unit PU Is the un It 
U3 of Fig.4. In this case, the position code "0000" Is as- 
signed to the child unit CU which represents more de- 
tails of the part in the lower left corner of the unit U3. On 
the basis of this position code "0000", "01 00" is assigned 
to the child unit CU which adjoins this child unit CU (hav- 
ing the position code "0000") in the east longitude direc- 
tion. Similarly, the position code Is incremented by 
"01 00" each time the position of the child unit CU shifts 
one position In the east longitude direction. Further, on 
the basis of the position code "0000," "0001" Is assigned 
to the child unit CU which adjoins the child unit CU (hav- 
ing the position code "0000") in the north latitude direc- 
tion. Similarly, the position code Is Incremented by 
"0001 " each time the position of the child unit CU shifts 
one position in the north latitude direction. 
[0060] According to the position codes thus assigned, 
the unit U2, one of the child units CU of the unit U3, is 
provided with the position code "0401 ." 
[0061] Next, suppose that the parent unit PU is the 
unit U2. This unit U^, too, has 64 child units CU at the 
level Immediately below (the level "1"). As shown In Fig. 
4, the position codes are assigned in the above-de- 
scribed manner to the 64 level-one child units CU. For 
example, the unit U^. one of the child units CU of the 
unit U2. is provided with the position code "0503." 
[0062] Also, the unit U^ as a parent unit PU has 64 
child units CU at the level immediately below (the level 
"0"). Position codes are similarly assigned as shown In 
Fig.4 also to the level-"0" child units CU. For example, 
the unit Uq. one of the child units CU of the unit U^, is 
provided with the position code "0201 ". 
[0063] Thus, the position code of this embodiment is 
incremented by predetemnlned quantities in the east 
longitude and north latitude directions as described 
above. Therefore it is easy to know the relation between 
neighboring child units CU. 

[0064] The terminal device 1 and the center station 2 
shown in Fig.1 each comprise a file system. The file sys- 
tem of the terminal device 1 Is composed of the data 
processing portion 1 3 and the read/write control portion 
1 8. In order to easily management of the first database 
1 1 1 in the first storage device 1 9, the file system of the 
terminal device 1 divides the storage region of the first 
storage device 1 9 Into some logic regions called "direc- 
tory." The file system of the terminal device 1 represents 
the parent-child relation and the neighboring relation be- 
tween the cartographic files CF in the first database 1 1 1 
with directory names and file names based on a tree 
structure. 

[0065] The file system of the center station 2 is com- 
posed of the received request analyzing portion 22 and 
the read control portion 23. The file system of the center 



station 2 divides the storage region of the second car- 
tographic files 24 in the second storage device 24 into 
"directories" (logic regions) and represents the parent- 
child relation and neighboring relation between the car- 
tographic files CF in the second database 25 with the 
directory names and file names based on a tree struc- 
ture. 

[0066] Fig.5 is a diagram showing the tree structure 
for managing the cartographic flies CF shown In Figs.2 
to 4. As stated above, the directories in each file system 
take a tree structure as shown in Fig.5 and are repre- 
sented with "¥." The mark "¥" is an Identifier for identi- 
fying the directory. The uppermost directory Is called 
root, which Is represented as '^MAP." Cartographic files 
CF themselves or subdirectories can be stored in the 
directories below the root directory "¥I\^AP." When spec- 
ifying a required cartographic file CF, the file system has 
to describe the names of the directories existing be- 
tween the root "¥IS/I AP" and the directory where that car- 
tographic file exists; the names of the directories are de- 
scribed as "path" in front of the file name. Thus a char- 
acter string sandwiched between two "¥" marks repre- 
sents a directory name. The initial of the subdirectory 
name Is defined as "D." The initial of the file name is 
defined as "M." Further, the extension of the file name 
is defined as ".map." 

[0067] Next, a method for assigning the directory 
names and file names is described, which is one of the 
features of this embodiment. First, basically, the carto- 
graphic files CF representing the maps covered by the 
Individual units at the highest level are provided with 
their file names according to the given rules and stored 
in the directories (logic regions) immediately below the 
root ("¥map"). For example, the unit Us shown in Fig.3 
belongs to the highest level (the level "3") and corre- 
sponds to the 1 6th unit from the origin in the east longi- 
tude direction and the 6th unit In the north latitude direc- 
tion (the origin is at latitude 0 degree and longitude 0 
degree: note that the unit containing the origin is num- 
bered 0th). Therefore the unit U3 is provided with the 
name "M1 606.map" including the initial of tlie file name 
and the extension. Further, since the unit U3 at the high- 
est level Is stored right below the root ("¥map"), its path 
is "¥MAP¥IVI1606.map. " 

[0068] As Is seen from the file name of the unit U3, a 
4-diglt number is interposed between the initial of the 
file name and the extension. The higher two digits of the 
number define the position of the unit U counted from 
the origin In the east longitude direction. The lower two 
digits of the number define the position of the unit U 
counted from the origin In the north latitude direction. In 
this way, the file name defines the position of the unit U. 
Also, as can be seen from the path of the unit U3, no 
subdirectory exists between the root ("xmap") and the 
file name, in this way, the number of subdirectories de- 
fines which level the unit U belongs to. In the case of the 
unit U3, the fact that the number of subdirectories be- 
tween the root and the file name is zero shows that the 
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unit U3 (M1606.map) belongs to the highest level. 
[0069] According to the rules above, the paths of other 
units U at the highest level are represented as: 
"¥MAP¥MOOOO.map." "¥MAP¥M0001 .map" ... 

"¥MAP¥M1606.nnap" ... 5 
[0070] Also, subdirectories for storing a group of units 
related to a highest-level unit U as their parent unit PU 
are formed immediately below the root. For example, in 
order to store the group of units U whose parent unit PU 
is the unit U3, a subdirectory named '^Dl 606" is formed 
right below the root. As Is seen from this subdirectory 
name, the initial of the subdirectory name Is followed by 
a 4-diglt number. Like that of the file name, this 4-digit 
number shows the position of the parent unit PU count- 
ed from the origin in the east longitude and north latitude 
directions. Thus "¥D0000," '"¥00001. map" ..."¥1606" ... 
are generated immediately below the root ("¥MAP"). 
[0071] Next, the individual units U belonging to the 
level "2" are provided with file names on the basis of 
their position codes and stored in the directories (logic 
regions) immediately below the subdirectories which 
represent their parent units PU. For example, refen'ing 
to Fig.4 etc., the unit U3 as a parent unit PU has 64 units 
U at the level "2". One of them, the unit Ug, has the po- 
sition code "0401 /' so that it Is named "M0401 .map" in- 
cluding the initial of the file name and the extension. The 
unit U2 at the level "2" is stored Immediately below the 
subdirectory ("¥map¥D1 606") of the unit U3 (parent unit 
PU), so Its path is "¥MAP¥D1606¥M0401 .map." 
[0072] As can be seen from the file name of the unit 
U2, the position code is interposed between the initial of 
the file name of the level-"2" unit U and Its extension. 
Thus the file name of a leve!-"2" unit U, too, defines the 
position of that unit U. Also, as can be seen from the 
path of the unit Ug, only a single subdirectory exists be- 
tween the root ("¥map") and the file name. The number 
of subdirectories defines which level the unit U belongs 
to. in the case of the unit Ug, since the number of sub- 
directories between the root and the file name Is 1 , It is 
known that the unit U2 (M0401 .map) belongs to the level 

[0073] According to the rules above, other paths at the 
level "2" are represented as: 
"¥MAP¥D0000¥MOOO0.map," 
"¥MAP¥D0000¥MOOO1 .map" ... 
"¥MAP¥D0000MOO07.map." 
"¥MAP¥DOOOO¥M0100.map" ... 
"¥MAP¥DOOOO¥M0707.map," 
"¥MAP¥D0001¥MO00O.map" ... 
"¥MAP¥D1606¥M0001.map" ... 
"¥MAP¥D01606¥M0401.map" ... 
"¥MAP¥D1606¥M0707.map" ... 

[0074] Similariy, the group of units related to the level- 
"2" unit U2 as their parent unit PU are stored below di- 
rectories (logic regions) below the subdirectory 
"^0401." For example, the unit Is one of the child 
units CU of the unit Ug and corresponds to the position 
code "0503" among the units U fonned by dividing the 



unit U2 into 64. Therefore the path for the unit U^ is rep- 
resented as "¥MAP¥D1606¥D0401¥M0503.map. Simi- 
larly, the paths of the level-"1" units related to the unit 
U2 as their parent unit PU are: 
'^MAP¥D1 606¥DO4O1¥00O0.map," 
"¥MAP¥D1606¥D0401¥M0001 .map"... 
"¥1VIAP¥D 1 606¥D0401 ¥0707.map." 
[0075] Further the group of units U related to the unit 
U^ as their parent unit PU are stored in directories (logic 
regions) immediately below the subdirectory 
*¥MAP¥D1606¥D0401¥D0503." Among the units U 
fonned by dividing the unit U^ into 64, the unit Uq be- 
longing to this group corresponds to the position code 
"0201." Therefore the path of the unit Uq Is: 
"¥MAP¥D1 606¥D0401¥D0503¥M0201 .map." Similar- 
ly, the paths of the level-"0" units related to the unit U.| 
as their parent unit PU are: 
••¥MAP¥D1606¥D0401¥D0503¥MOOOO.map," 
"¥I\/IAP¥D1606¥D0401¥D0503¥M0001 .map" ... 
"¥MAP¥D1 606¥D0401¥D0503¥M070 7.map." 
[0076] The hierarchical structure realized with the car- 
tographic files CF and their file names have been de- 
scribed. Digital data Is generated on the basis of the unit 
described so far and necessary management informa- 
tion is added to the data to form one cartographic file 
CF (see Fig.7 for details). In the description below, unit 
data means digital data representing a unit U. That is to 
say, one cartographic file CF contains one piece of unit 
data. Next, the data structure of the cartographic file CF 
is described In detail. 

<Data Structure of the Cartographic RIe CF> 

[0077] Flg.6 js a diagram used to explain a map ren- 
dered on the basis of one cartographb file CF. Fig.7 
shows the data structure of one cartographic file CF. Ba- 
sically, as shown In Fig.7, the cartographic file CF in- 
cludes a unit header and unit data. The unit data is de- 
scribed first. Generally, as shown in Fig.7, a map is 
formed with a background, roads, map symbols and 
characters, according to its usage. The cartographic 
files CF are mainly used to present an Image on the dis- 
play of the tenmlnal device 1 or used in nnap matching 
or route search process. For example, while the route 
search, process requires information about connections 
among roads, the background is not much required in 
this process. Therefore, as shown in Fig. 6, a piece of 
unit data Is divided into character/symbol data, road net- 
work data and background data. This allows the char- 
acter/symbol data, road network data and background 
data to be used individually. The character/symbol data 
Includes data which represents character strings de- 
scribed on the map which the unit U covers (the names 
of places. Intersections, etc.) and data which represents 
map symbols described on that map. The road network 
data is graphic data which represents roads shown on 
the map of the unit U and the connections among them. 
The background data is graphic data which represents 
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the background on the map the unit U covers, such as 
water systems, mountains, buildings, etc. Examples of 
the background include rivers, lakes, mountains, green 
belts, railroads, buildings, bridges, and parks. The char- 
acter/symbol data, the road network data and the back- 
ground data are displayed in a superimposed manner 
to show the background, roads, map symbols and char- 
acters by the unit data. 

[0078] Next, the data structure of the background data 
is explained In detail referring to Flgs.7 and 8. As shown 
in Fig.7, the background data Is composed of a basic 
background table and a detailed background table. As 
can be clearly seen from Flg.8(a), the basic background 
table is a group of graphic data which Is used as the 
base when disjDlaying the background of the map, which 
shows a river, a railroad, and a green belt, for example. 
On the other hand, as Is clear from Rg.8(b), the detailed 
background table Is a group of graphic data which is 
used to display greater details of the background of the 
map, such as bridges, buildings, etc. As is clear from 
Fig.7, the basic background table and the detailed back- 
ground table are separately recorded in the unit data. 
Furthemiore, infomnation which would be referred to by 
each other is not recorded in the basic background table 
and the detailed background table. That is to say, the 
background data in the detailed background table is 
never referred to during the process of drawing the 
background data of the basic background table. At the 
same time, the background data in the basic back- 
ground table is never referred to during the process of 
drawing the background data of the detailed back- 
ground table. The basic background table and the de- 
tailed background table thus have their own independ- 
ent data structures. Accordingly, the background ex- 
pressed by the basic background table alone can be dis- 
played on the display, as shown In Fig.8(a). Then the 
user of the terminal device 1 can see a schemata map. 
The background expressed by the basic background ta- 
ble and the detailed background table can also be dis- 
played as shown in Fig.8(c). In this case, on the basis 
of a given origin, the detailed background extracted from 
the detailed background table Is superimposed on the 
rough background extracted from the basic background 
table. The user of the terminal device 1 can then see a 
detailed map. This embodiment shows an example in 
which the background data includes the basic back- 
ground table and the detailed background table; how- 
ever, when thef irst storage device 1 9 or the second stor- 
age device 24 has limited storage capacity, the back- 
ground data may be fomned with only the basic back- 
ground data, so as to achieve size reduction of the first 
database 111 or the second database 25. On the other 
hand, when the background data Is formed with the ba- 
sic background table and the detailed background table 
as explained in this embodiment, the center station 2 
can provide a detailed map to the terminal device 1, 
which allows the terminal device 1 to display a detailed 
map on the display. 



[0079] The above-described basic background table 
and detailed background table have the same internal 
data structure. Their data structure is now described in 
greater detail, where the basic background table and the 
5 detailed background table are generlcally referred to as 
a background table. 

[0080] As already stated, the background table is a 
group of graphic data used to draw the background of 
a map on the display. The graphic data express rivers, 

10 parks, factories, railroads, etc. on the display. The ele- 
ments of the background of the map, i.e. rivers, parks, 
factories, railroads, etc., are generically refen'ed to as 
rendered objects hereinafter. Fig.9 is a diagram showing 
the concept of the rendered objects. As is clear from the 

IS description above, a rendered object represents an ob- 
ject which shows something meaningful by Itself, like a 
park, factory, etc., whose data structure Includes ele- 
ment points arranged to express the object with a bent 
line. For example, Rg.9 shows a rectangular unit U. The 

^0 area covered by the unit U contains two rendered ob- 
jects D01 and D02. The rendered object DDI Includes 
objects OBJ1 and 02. The object OBJ1 con-esponds to 
the region surrounded by the bent line drawn with one 
stroke in the following order element point a -> elenient 

25 point b element point c -> element point d -> element 
point e -> element point a. The object OBJ2 corresponds 
to the region surrounded by the bent line drawn with one 
stroke in the following order: element point f element 
point g element point h -> element point i element 

30 point f. The rendered object D02 includes an object 
0BJ3. The object OBJ3 corresponds to the region sur- 
rounded by the bent line drawn with one stroke in the 
following order: element point J -> element point k -> el- 
ement point I element point m ^ element point n -> 

35 element point j. As is clear from this, a rendered object 
of this embodiment is composed of one or more objects 
fomned by connecting a plurality of element points with 
one stroke. 

[0081] Fig.1 0 is a diagram showing the detailed data 
40 Structure of the background table, i.e. the basic back- 
ground table or the detailed background table. In Fig. 
10, the background table contains the number of back- 
ground records M and M pieces of background records 
BR1 to BRM. M is a natural number of 1 or larger. The 
45 number of background records M Is Infomnation Indicat- 
ing the number of background records BR1 to BRM con- 
tained in the background table. The background record 
BR1 contains the background attribute, the number of 
objects N, the numbers of element points in the objects 
50 OBJ1 to ON, N1 to NN, and the object records OR1 to 
CRN. 

[0082] The background attribute Is information about 
attribute of the background expressed by the objects 
OBJ contained In the background record BR1. More 
55 specifically, the background attribute contains a color 
code and texture mapping code of the objects OBJ in 
the background record BR1. As one feature of this em- 
bodiment, the background attribute describes only one 
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color code or texture mapping code. That is to say, for 
example, a color code representing blue and a color 
code representing red are never described together in 
the background attribute. Only the color code "blue" or 
the color code "red" Is described in the background at- 5 
tribute. 

[0083] The number of objects, N, is Information indi- 
cating the number of objects OBJ contained In the back- 
ground record BR1 . The number of element points, N1 , 
shows the number of element points forming the object 
OBJ1. The number of element points, N2, shows the 
number of element points forming the object OBJ2. Sim- 
ilarly, the number of element points NN shows the 
number of element points of the object OBJN. In this 
way, the background record BR1 contains the numbers 
of element points fomrilng N pieces of objects O con- 
tained therein. N Is a natural number of 1 or larger. 
[0084] The object record OR1 Is Infomnatlon indicat- 
ing the coordinates of the element points forming one 
object OBJ1 . It should be noted that, since the object 
OBJ1 contains a plurality of element points, the object 
record 0R1 contains a plurality of sets of coordinate In- 
formation. That is to say, the object record OR1 de- 
scribes information about a string of coordinates. As is 
clear from this, the number of pieces of the coordinate 
Information described in the object record ORi corre- 
sponds to the number of element points N1 . The object 
record OR2 is infomnatlon about a string of coordinates 
of the element points forming the object OBJ2. The 
number of pieces of the coordinate information de- 
scribed In the object record OR2 is equal to the number 
of element points, N2. Similariy, the object record ORN 
is Infomiation indicating a string of coordinates of the 
NN -element points fomrilng the object OBJN. The 
number of pieces of the coordinate Information de- 
scribed in the object record ORN corresponds to the 
number of element points, NN. 

[0085] As described above, each object record OR 
describes a string of coordinates of the element points 
fomrilng the object OBJ. The string of coordinates may 
be expressed by the absolute coordinates In the unit U 
or by the relative coordinates, i.e. a difference between 
the coordinates of an element point and those of the pre- 
ceding element point. The absolute coordinates, which 
define the element points on the basis of a given origin 
In the unit U, require a large number of bits. Therefore, 
in order to reduce the data size of the cartographic file 
OF, It is preferable to use the relative coordinates to rep- 
resent the string of coordinates. The absolute coordi- 
nates and the relative coordinates are now described In 
detail. 

[0086] Fig.11 is a diagram used to explain the fact that 
the absolute coordinates require a large number of bits. 
Fig.11 shows graphic data composed of the eight ele- 
ment points PO to P7. The element point PO is defined 
by the absolute coordinates (XO, YO) on the basis of a 
predetermined origin. Similarly, the element points PI 
to P7 have their absolute coordinates (XI, Y1) to (X7, 
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Y7). Flg.12 Is a diagram showing the absolute coordi- 
nate information about the points PO to P7 described in 
the object record OR. Now, in the absolute coordinates 
of each of the element points PO to P7, the coordinate 
In the east longitude direction (x-axis direction) and that 
in the north latitude direction (y-axis direction) are each 
expressed in 2 bytes in this example; in this case, de- 
scribing the absolute coordinate information about the 
points PO to P7 in the object record OR requires 32 
bytes. 

[0087] ng.13 shows the element points PO to P7 of 
the same graphic data of Fig.11 with the relative coor- 
dinates. In Fig. 1 2, the graphic data is drawn by connect- 
ing the element points with one stroke in the following 
order: P0->P1^P2->P3-^P4-^P5-^P6->P7. In the rel- 
ative coordinate representation, as in the absolute co- 
ordinate representation, the first element point PO in the 
stroke Is represented as (XO, YO) on the basis of a given 
origin. However, while the next element point PI is rep- 
resented as (XI , Y1 ) in the absolute coordinate repre- 
sentation, the relative coordinates represent the ele- 
ment point P1 as (AX1, AY1), Where AX1 is defined as 
AX1=X1-X0 and AY1 as A Y1=Y1-Y0. Other element 
points P2 to P7, too, are each represented by using the 
difference between their absolute coordinates and the 
absolute coordinates of the preceding element point. 
[0088] Fig. 1 4 is a diagram showing the data structure 
where the relative coordinate infomiation about the el- 
ement points PO to P7 is described in the object record 
OR. It should be noted that, in the relative coordinate 
representation, AX1«X1 , AX2«X2 ... AX7«X7, since 
they are represented as differences between their ab- 
solute coordinates and the absolute coordinates of the 
preceding element points. Similariy, AY1«Y1, 
AY2«Y2 ... AY7«Y7. Accordingly, in the relative coor- 
dinates of the element points PI to P7, the coordinate 
in the east longitude direction (x-axis direction) and that 
in the north latitude direction (y-axis direction) are each 
expressed not in 2 bytes but in 1 byte. As a result, de- 
scribing the relative coordinate information about the el- 
ement points PI to P7 in the object record OR requires 
14 bytes. However, since the first element point PO has 
to be described by its absolute coordinates, describing 
the coordinate Information about the element points PO 
to P7 In the object record OR requires 19 bytes, Includ- 
ing the Infomnatlon about the number of differences (7). 
[0089] As described referring to Figs. 11 to 14, the el- 
ement points P in the object OBJ can be expressed in 
a smaller-sized object record OR by using the relative 
coordinates, than by using only the absolute coordi- 
nates. However, when the element points of the object 
OBJ are unconditionally represented by the relative co- 
ordinates, the data size will not be reduced in some cas- 
es. This problem is now described referring to Fig.15. 
Fig. 15 shows an object OBJ composed of element 
points PO, PI and Pn. The element point PI is repre- 
sented by the relative coordinates (AX1 , AY1). It is as- 
sumed that AX1 and AY1 can be represented in one 
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byte each. Similarly, the element point Pn is represented 
by the relative coordinates (AXn, delta Yn). It Is as- 
sumed, however, that AXn and/or AYn cannot be repre- 
sented in one byte since the element point Pn is so dis- 
tant from the preceding element point P1. In such a 
case, as shown in Fig.16, new element points P2 and 
P3 must be set on the straight line connecting the ele- 
ment points P1 and Pn. Then the relative coordinates of 
the element point Pn Is represented as (AX4, AY4) with 
respect to the absolute coordinates of the preceding el- 
ement point P3. The coordinates AX4 and AY4 can be 
represented in one byte each, since the element point 
P3 Is closer to the element point Pn than the element 
point PI. When the relative coordinate infomnation 
about the element points PO, PI , P2, PS and Pn is de- 
scribed in the object record OR, 13 bytes are required 
as shown In Fig. 17. 

[0090] As described referring to Flgs.15 to 17, new 
element points P must be provided when two element 
points P are located at a distance. As a result, it is nec- 
essary to describe the relative coordinate information 
about the supplementary element points P in the object 
record OR. In this way, when all of the element points P 
other than the first element point P are represented by 
the relative coordinates, the number of element points 
P may be unnecessarily increased, which will unneces- 
sarily increase the data size of the object record OR. It 
Is therefore effective to represent the element points PO 
and Pn of Fig. 15 by their absolute coordinates and the 
element point P1 by the relative coordinates with re- 
spect to the element point PO. Now, assuming that the 
absolute coordinates (Xn, Yn) of the element point Pn 
can be represented in 4 bytes, the coordinate informa- 
tion about* PO, PI arid Pn Is describi^d ih the object 
record OR as shown in Fig, 18, In Flg.18, the absolute 
coordinate Information about the element points PO and 
Pn is each represented in 4 bytes and the relative coor- 
dinate Infomnation about the element point PI is repre- 
sented In 2 bytes. Further, 2 bytes are used to represent 
the information about the number of differences which 
shows how many relative coordinates have been pro- 
duced on the basis of PO and Pn represented by the 
absolute coordinates. The data size of the object record 
OR Is thus 12 bytes In total. This data size is smaller 
than that of the object record OR represented only by 
the relative coordinates. I.e., 13 bytes (see Fig. 17). 
[0091] As has been described referring to Fig.18, an 
element point far off from the preceding element point 
Is represented by the absolute coordinates. In this way, 
In this embodiment, while an element point is mainly rep- 
resented by the relative coordinates, another element 
point Is represented by the absolute coordinates. This 
reduces the data size of the object record OR. 
[0092] Further, as already stated, the relative coordi- 
nate representation is applied also to the boundaries be- 
tween objects in this embodiment. The boundary be- 
tween objects means a part where pen-up occurs from 
one element point P of one object OBJ and pen-down 
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occurs onto one element point P of another object OBJ. 
The application of the relative coordinate representation 
of this embodiment provides the technical effect of re- 
ducing the data size of the background table. Now, first, 

5 in order to cleariy show this technical effect, an example 
In which the relative coordinate representation is not ap- 
plied to the boundary between objects will be described 
referring to Rgs.19 and 20. Fig.19 shows a rendered 
object DOS. The rendered object BOS includes objects 

10 OBJS and OBJ4. The object OBJ3 Is fomied with six 
element points PO to PS. The object OBJ4 Is fonmed 
with four element points P6 to P9. 
[0093] The object OBJS is drawn by connecting the 
element points with one stroke in the following order: 

IS P0-*P1-^P2-»P3->P4->P5->P0. Then pen-up occurs 
at the element point PO and pen-down occurs at the el- 
ement point P6. The object OBJ4 is then drawn by con- 
necting the element points with one stroke In the follow- 
ing order. P6-»P7->P8-^P9^P6. At this time, when the 

20 retath/e coordinates are not applied to the boundary be- 
tween the objects, the coordinate data structure of the 
element points PO to P5 and the element points P6 to 
P9 is generated as shown In Fig.20. In Fig.20, first, the 
absolute coordinates (XO, YO) of the element point PO 

25 used as the reference point of the object OBJS are de- 
scribed in four bytes. When drawing the object OBJS, 
pen-down occurs at the element point PO and then the 
element points P1 to P5 are traced before pen-up, so 
that the number of differences (i.e. the number of rela- 

30 tive coordinate sets) is 5, which Is 1-byte infomnation. 
Next, the relative coordinates of the element points PI 
to P5 are represented in two bytes as stated above, as 
(AX1 , AY1) to (AX5, AYS). Since the relative coordinate 
representation is not applied to the boundary between 

35 the objects, the relative coordinates of the element point 
P5 are followed by the 4-byte absolute coordinates {XI , 
Y1) of the element point P6 which is used as the refer- 
ence point of the object OBJ4. When drawing the object 
OBJ4, pen-down occurs at the element point P6 and 

40 then the element points P7 to P9 are traced before.pen- 
up, so that the number of differences (the number of rel- 
ative coordinate sets) is 3, which Is 1-byte infonnatlon. 
This Is followed by the relative coordinates of the ele- 
ment points P7 to P9 each in two bytes, as (AX6. AY6) 

45 to (AX8, AYS). Thus, when the relative coordinate rep- 
resentation Is not applied to the boundary between the 
two objects, the string of relative coordinates represent- 
ing the objects OBJ3 and OBJ4 are expressed in 26 
bytes. 

50 [0094] Next, an example in which the relative coordi- 
nate representation is applied to the boundary between 
objects will be described referring to Figs,21 and 22. 
Like Fig.19, Fig.21 shows the rendered object DOS in- 
cluding two objects OBJS and OBJ4. The rendered ob- 

55 ject DOS is drawn by connecting the element points with 
one stroke in the following order: 
P0-*P1-»P2-»P3->P4->P5. Then pen-up and pen- 
down occur from the element point P5 to the element 
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point P6 and the rendered object DOS is then drawn by 
connecting the element points with one stroke in the fol- 
lowing order P6-»P7->P8->P9^P6. In drawing, there 
is a basic rule that the starting point of one stroke should 
be connected to the pen-up point, so that the element 
point P5 and the element point PC are connected by a 
line. At this time, when the relative coordinate represen- 
tation is applied to the boundary between the objects, 
the coordinate data structure of the element points PO 
to P5 and P6 to P9 Is generated as shown in Fig.22, In 
Flg.22, first, the absolute coordinates (XO, YD) of the el- 
ement point PO used as the reference point of the object 
OBJ3 is described in four bytes. When drawing the ren- 
dered object D03, the one stroke starts at the element 
point PO and traces the element points PI to P9 before 
It is completed, so that the number of relative coordi- 
nates. I.e. the number of differences, is 9, which Is 1 -byte 
data. Each set of relative coordinates of the element 
points P1 to P9 is expressed in two bytes as stated 
above, as (AX1, AY1) to (AX9, AY9). Thus, when the 
relative coordinate representation is applied to the 
boundary between the two objects, the string of relative 
coordinates showing the objects OBJ3 and OBJ4 are 
expressed in 23 bytes. 

[0095] As has been described above referring to Figs, 
19 to 22, the background table can be smaller In size 
when the relative coordinate representation is applied 
to the boundary between objects, than when it Is not ap- 
plied thereto. 

[0096] Note that the boundary between the objects of 
Flg.20 can be found from the absolute coordinates de- 
scribed in the object record OR. In Fig.22. however, the 
boundary between the objects cannot be found from the 
absolute coordinates. This is because the pen-up ele- 
ment point P and the pen-down element point P which 
define the boundary between the objects may be repre- 
sented, as shown In Fig.21 , by the relative coordinates; 
further, when two points are far from each other, the el- 
ement point P may be represented by the absolute co- 
ordinates as shown In Flg.18. However, in Fig.22, the 
boundary between the objects can be correctly identi- 
fied by referring to the numbers of element points, N1 
to NN, shown In Fig. 10. That Is to say, In this embodi- 
ment, the number of element points N1 toNN each show 
the number of element points which are traced with one 
stroke between pen-down and pen-up. Accordingly, In 
actual drawing operation, the number of coordinates is 
counted from the beginning of the object record OR and 
the border of the first object can be correctly identified 
when the counted value is the same as the number of 
element points N1 . Similarly, when the counted value is 
the same as the sum of the numbers of element points 
N1 and N2, the border of the second object can be spec- 
ified. Subsequently, similarly, the border of an Nth object 
can be identified when the counted value is the same 
as the sum of the numbers of element points N1 to NN. 



(Detailed Data Structure of the Character/Symbol Data) 

[0097] Next, the character/symbol data shown In Fig. 
7 is described. It is briefly described because the char- 

5 acter/symbol data is not a characteristic point of this In- 
vention. As already stated, the character/symbol data is 
composed of data about the character strings described 
on the map which the unit U covers (the names of plac- 
es, roads, intersections, etc.) and data about the map 

10 symbols described on the map. As shown in Fig.7, the 
character/symbol data includes a basic character/sym- 
bol table and a detailed character/symbol table. The ba- 
sic character/symbol table Is a group of data which rep- 
resents basic ones of the character strings and map 

15 symbols described on the map the unit U covers. More 
specifically, as clearly shown in Fig.23(a), the basic 
character/symbol table contains character strings and 
map symbols which schemattoally show the map the 
unit U covers, which may include the names of rivers 

20 and roads, map symbols, etc. The detailed character/ 
symbol table is a group of data which represents char- 
acter strings and map symbols which are not described 
in the basic character/symbol table among the character 
strings or map symbols described on the map covered 

25 . by the unit U. More specif bally, as cleariy shown In Fig. 
23(b), the detailed character/symbol table contains 
character strings and map symbols which show more 
details of the map the unit U covers, such as the names 
of parks, railroads, bridges, factories, etc. 

30 [0098] The terminal device 1 of this embodiment is 
supposed to be a car navigation system as stated 
above. For this reason, it has been described that the 
basic character data table contains the names of rivers 
and roads, map symbols, etc., which are Important for 

35 car navigation. However, the tennlnal device 1 can be 
used for other purposes. Thus, the contents of the char- 
acter strings and map symbols recorded in the basic 
character/symbol table and the contents of the charac- 
ter strings and map symbols recorded in the detailed 

40 character/symbol tabie depend on the application of the 
terminal device 1 . It should hence be understood that 
the technical scope of this invention is not limited to the 
description which says that the names of rivers and 
roads, map symbols etc., are recorded In the basic char- 
acter data table. 

[0099] As can be clearly seen from Flg.7, the basb 
character/symbol table and the detailed character/sym- 
bol table are recorded in different fields in the unit data. 
Further, no information which would be referred to by 

50 each other is recorded in the basic character/symbol ta- 
ble and the detailed character/symbol table. That is to 
say, none of the character strings or map symbols in the 
detailed character/symbol table is referred to during the 
process of drawing the character strings or map sym- 

55 bols in the basic character table. Gonyersely. none of 
the character strings and map symbols in the basic char- 
acter/symbol table is referred to during the process of 
drawing the character strings and map symbols in the 
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detailed character/symbol table. In this way, the basic 
character/symbol table and the detailed character/sym- 
bol table have their own Independent data structures. 
Therefore, as shown In Flg.23(a), the character strings 
and map symbols represented by the basic character/ 
symbol table alone can be shown on the display. This 
allows the user of the terminal device 1 to see a sche- 
matic map. Further, as shown In Fig.23(c), It is also pos- 
sible to display the character strings and map symbols 
of the basic character/symbol table and the detailed 
character/symbol table. In this case, on the basis of a 
given reference origin, the character strings and map 
symbols extracted from the detailed character/symbol 
table are superimposed on the schematic character 
strings and map symbols extracted from the basic char- 
acter/symbol table. This allows the user of the terminal 
device 1 to see a detailed map. This embodiment has 
shown an example in which the character/symbol data 
is composed of the basic character/symbol table and the 
detailed character/symbol table; however, when, for ex- 
ample, the first storage device 1 9 or the second storage 
device 24 has limited storage capacity, the character/ 
symbol data may be fonrned of only the basic character/ 
symbol table. In order to achieve size reduction of the 
first database 111 or the second database 25, On the 
other hand, when the character/symbol data is conrv 
posed of the basic character/symbol table and the de- 
tailed character/symbol table as described in this em- 
bodiment, the center station 2 can provide the terminal 
device 1 with a detailed map, allowing the temninal de- 
vice 1 to display a detailed map on the display. 
[0100] The basic character/symbol table and the de- 
tailed character/symbol table have the same Internal da- 
ta structure. Now, gehericaliy ref erilhg to the basic char- 
acter/symbol table and the detailed character/symbol 
table as a character/symbol table, their data structure is 
described in greater detail. 

[01 01 ] As stated above, the character/symbol table is 
a group of data for showing, on the display, character 
strings and map symbols on the map the unit U covers. 
Fig.24 is a diagram showing the detailed data staicture 
of the character/symbol table, i.e. the basic character/ 
symbol table or the detailed character/symbol table. In 
Fig.24, the character/symbol table contains the number 
of character/symbol records P and P pieces of charac- 
ter/symbol records TSR1 to TSRR The number of char- 
acter/symbol records P is Information indicating the 
number of character/symbol records TSR1 to TSRP 
contained in the character/symbol table; P is a natural 
number of 1 or larger, indicating the total number of the 
character strings and map symbols on the map the unit 
U covers. The number of the character/symbol records 
TSR1 to TSRP is equal to the number of character 
strings and map symbols on the map of the unit U. The 
character/symbol record TSR1 Includes the character/ 
symbol attribute, point coordinates, and a character/ 
symbol code. 

[0102] The character/symbol attribute contains infor- 



mation indicating attributes of the character string or 
map symbol represented by the character/symbol 
record TSR1 . The character/symbol attribute includes 
information indicating the size of the character string or 

5 map symbol and the direction in which the character 
string is anranged (vertlcal/horizontel). It should be not- 
ed that, for the map symbol, one object is hardly repre- 
sented by a plurality of symbols, and the names of some 
places are expressed by one character, in such a case, 

10 it is not necessary to record the information showing the 
direction of the character string arrangement (vertical/ 
horizontal) in the character/symbol attribute. The point 
coordinates are coordinate infomnation which specifies 
the position where the character string or map symbol 

15 of the character/symbol record TSR1 is displayed on the 
unit U. The character string or the like represented by 
the character/symbol record TSR1 is displayed on the 
display in the position specified by the point coordinates. 
The character/symbol code is the code number of the 

20 character string or map symbol represented by the char- 
acter/symbol record TSR1 . The code number of the 
character string typically Includes the shift J IS code in 
Japan, which is recorded as information corresponding 
to the size of the character string which is recorded in 

25 the character/symbol attribute. Since there is no stand- 
ard like the shift JIS about the map symbols, they are 
created originally. For the code numbers of the map 
symbols, unused code numbers in the shift JIS are used 
in Japan. The allotted code number is recorded as the 

30 character/symbol code. 

[0103] Other character/symbol records TSR2 to 
TSRP are not described herein since they have the 
same data structure as the character/symbol record 
TSR1. 

35 

(Detailed Data Structure of the Road Network Data) 

[0104] Next, the road network data shown in Fig.7 is 
described. While the road network data is used to dis- 

"^0 play roads on the display in the terminal device 1 as a 
car navigation system, it is also used for the purposes 
of map matching, route search or route guide. There- 
fore, as stated before, the road network data is a group 
of data which Includes graphic data for representing 

45 roads shown on the map the unit U covers and data for 
showing the connections among the roads. More spe- 
cifically, since the road network data Is used for map 
matching etc., it contains not only the graphic data rep- 
resenting the road network configuration but also data 

50 representing the connections among the roads shown 
on the map In the area the unit U covers. 
[0105] As shown In Flg.7, the road network data in- 
cludes first network data and second network data. The 
first network data contains road network data about 

55 highways. The highways mean roads which satisfy any 
of the three conditions beiow. The first condition defines 
roads constructed by a local government or a higher ad- 
ministrative organization (freeways and national roads). 
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The second condition defines roads constructed by an 
administrative organization lower than the local govern- 
nnent (freeways and national roads) and private roads 
which have a width of 5.5 meters or larger. The third con- 
dition defines roads connected to roads which satisfy 
the first and second conditions. The second network da- 
ta contains road network data about streets. The streets 
are roads, other than the highways, which have a width 
of 3.0 meters or larger (for example, roads constructed 
around houses). However, the definitions of the high- 
ways and streets are mere examples and other defini- 
tions can be adopted. It should therefore be understood 
that the technical scope of this Invention is not limited 
to the above description which says that the road net- 
work data defined as above are recorded In the first and 
second road network data. 

[0106] Next, the relation between the first road net- 
work data and the second road network data Is de- 
scribed referring to Fig.26. The first road network data 
includes road network data about highways. Hence, 
when the first road network data Is displayed on the dis- 
play of the temninal device 1 . figures representing high- 
ways are displayed as shown in Fig.25(a). The second 
road network data is road network data about streets. 
Hence, when the second road network data is displayed 
on the display of the temninal device 1, figures repre- 
senting streets are displayed as shown in Fig.25(b). As 
is clear from Fig. 7, the first and second road network 
data are separately recorded in the unit data. It is there- 
fore possible to display, on the display of the terminal 
device 1 , only the highways of thef Irst road network data 
as shown In Fig.25(a). This allows the user of the temni- 
nal device 1 to see a schematic road network. It is also 
possible to display the highways and streets of theflrst 
and second road network data as shown in Fig.25 (c). 
In this case, the street network of the second road net- 
work data is superimposed on the highway network of 
the first road network data on the basis of a given refer- 
ence origin. The user of the terminal device 1 can thus 
see a detailed road network. This embodiment de- 
scribes that the road network data is composed of first 
and second road network data; however, for example, 
when the first storage devbe 1 9 or the second storage 
device 24 has limited storage capacity, the road network 
data may be composed of only the first road network 
data, so as to achieve size reduction of theflrst database 
111 or second database 25. On the other hand, when 
the road network data includes the first and second road 
network data as in this embodiment, the center station 
2 can provide a detailed road network to the terminal 
device 1 , which allows the temninal device 1 to display 
a detailed road network on the display, 
[0107] The first and second road network data have 
the same data structure. The structure of the first and 
second road network data will be described in greater 
detail. 

[0108] As is known, road network data is mainly 
formed with nodes and links. The node is data which 



mainly represents an intersection or a section point on 
a road. The link is data which expresses a road connect- 
ing two intersections. The nodes and links are used to 
display, on the display of the terminal device 1 , the con- 

5 figuration of roads in the map of the unit U (highways or 
streets) and the connections among the roads. As 
shown In Fig.7, the first road network data Includes a 
first node table and a first link table, and the second road 
network data includes a second node table and a sec- 

10 ond link table. The data structure of the first and second 
node tables Is now described. 

[01 09] Fig.26 is a diagram used to explain theconcept 
of the nodes and links. Fig.26 shows a road network in 
the area one unit U covers. The road network of Fig.26 

15 is formed with 11 nodes NO to N10 and 11 links LO to 
L10. The 11 nodes NO to N10 are generally classified 
Into non-neighboring nodes and neighboring nodes. 
The non-nelghboring node Is a node which is generated 
at an ordinary intersection or at a point where the road 

20 type or attribute changes (which corresponds to the 
aforementioned section point), which stands for a 
branching point representing the connection between 
the roads in the unit U. Now, some units U at the same 
level adjoin the unit U of Fig.26 (see Fig.2). Therefore 

25 one road may pass through a plurality of adjacent units 
U. In the description below, forthe sake of convenience, 
the units U which adjoin the unit U of Fig.26 are referred 
to as neighboring units NU. Fig.26 shows one of the 
neighboring units NU with a dotted line. When a road 

30 passes over the boundary between the unit U of Fig.26 
and a neighboring unit NU, a neighboring node isfomned 
on the boundary of the unit U (i.e. on a side of the rec- 
tangular area), which point represents the connection of 
road between the unit U and the neighboring unit NU.. 

35 According to this definition, the four nodes N1 , N2, N5 
and N8 of Fig.26 (shown byO) are classified as the non- 
neighboring nodes. Also, the seven nodes NO, N3, N4, 
N6, N7, N9 and N1 0 (shown by •) are classified as the 
neighboring nodes. It should be noted that when a node 

40 N representing an intersection or a section point of a 
road Is located on the boundary of the unit U, a problem 
arises as to whether this node N should be classified as 
a neighboring node or as a non-nelghboring node. In 
such a case, for one measure, the node N representing 

45 an Intersection or a section point of the road may be 
shifted from the boundary to form a new non-nelghbor- 
ing node. For another measure, a non-neighboring node 
may be formed at the same coordinates as the intersec- 
tion or the section point of the road located on the bound- 
so ary of the unit U. As is clesur from this, a neighboring 
node should not be fomned on the boundary of the unit U. 
[0110] Fig. 27 is a diagram showing the detailed data 
structure of the first node table. Note that the first and 
second node tables have the same data structure but 

55 they differ in that they are generated for highways and 
streets, respectively. Therefore, for simplicity, the sec- 
ond node table is not fully described herein. Now, in Fig: 
27, the first node table contains the number of nelghbor- 
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ing nodes, Q. the number of non-neighboring nodes, R, 
and (Q+R) pieces of node records NR1 to NR(Q+R). 
The number of neighboring nodes, Q. is infomnation 
which shows the number of neighboring nodes con- 
tained in the first node table. Q is a natural nunnber of 1 
or larger, which shows how many neighboring nodes are 
present on the road networi< in the map of the unit U. 
The number of non-neighboring nodes, R, is infomnation 
which shows the nuniber of non-neighboring nodes con- 
tained in the first node table. R Is a natural number of 1 
or larger, which shows how many non-neighboring 
nodes exist on the road network in the map of the unit U. 
[0111] The number of the node records NR1 to NR 
(Q+R) Is equal to the number of nodes N present on the 
road network of the map of the unit U. The node records 
NR1 to NR(Q+R) contain Infomnation about the (Q+R) 
nodes N. 

[0112] Next, how the node records NR1 to NR(Q+R) 
are arranged In this embodiment is described. In the first 
node table, the first Q node records NR1 to NRQ contain 
information about the Q neighboring nodes and the fol- 
lowing R node records NR(Q+1) to NRR contain infor- 
mation about the R non-neighboring nodes. 
[0113] In the Q node records NR1 to NRQ, first, the 
information about the neighboring nodes located on the 
left side (see® of Fig.26) of the rectangular area (unit 
U) is recorded at the beginning. This is followed by the 
information about the neighboring nodes located on the 
upperside of the rectangular area (see®oi Fig.26). This 
is further followed by the information about the neigh- 
boring nodes on the right side of the rectangular area 
(see® of Flg.26) Finally, the information about the 
neighboring nodes on the lower side of the rectangular 
area is recorded (see (3)of Rg.26). 
[0114] The node records NR of the neighboring nodes 
on the right side or left side are arranged in the order of 
ascending latitudes. The node records NR of the neigh- 
boring nodes on the right side or left side are arranged 
in the order of ascending longitudes. 
[0115] Further, the node records NR of the non-neigh- 
boring nodes are, at first, arranged In the order of as- 
cending latitudes. If some non-neighboring nodes are at 
the same latitude, these node records NR are arranged 
in the order of ascending longitudes of the non-neigh- 
boring nodes. 

[0116] For the nodes NO to N10 of Flg.26, according 
to the rules, the information about the neighboring node 
N6 is recorded In the first node record NR1 as shown In 
Fig.28. The information about the neighboring node NO 
is recorded in the next node record NR2. The pieces of 
information about the neighboring nodes N4, N7, N10, 
N3 and N9 are recorded In the node records N R3, N R4, 
NR5, NR6 and NR7, respectively. Signs ®to@of Fig. 
28 con^espondto0to(3)of Fig.26, which show the order 
in which the neighboring nodes are arranged. The Infor- 
mation about the non-neighboring node NB is recorded 
In the next node record NR8. The pieces of infomnatibn 
about the non-neighboring nodes N5, N2 and N1 are 



recorded in the node records NR9, NR1 0 and NR1 1 , re- 
spectively. In this embodiment, the infonmation pieces 
about the nodes N contained in the unit U are thus re- 
corded in the node records NR not at random but in the 
5 order according to the rules above. In the description 
below, node record numbers are numbers which specify 
where the node record NR2 and others are recorded, 
counted from the first node record NR1 numbered 0. 
When the node record number Is applied to the node 
10 reconjs NR1 to NR11 of Fig.28, the node record num- 
bers of the node records NR1 to NR11 are "0" to "10." 
This arrangement produces the effects that the connec- 
tion of a road passing over the unit U and the neighbor- 
ing unit NU can be traced at high speed and that the 
75 nodes and links can be properly associated with each 
other between parent/child units U; these processes 
and effects will be fully described later. 
[0117] Refen^lng to Flg.27 again, the Internal data 
structure of the node record NR1 is described In detail. 
20 The node record NR1 Includes node attributes, node co- 
ordinates and node connection infomnation. The node 
attributes are information indicating attributes of the 
node recorded in the node record NR1 . Examples of the 
node attributes Include information Indicating whether 
25 the traffic is regulated at the Intersection of the recorded 
node, infomnation indicating whether the intersection 
represented by the node has a name, and Information 
indicating whether the intersection represented by the 
node has trafTic signals. When the information about the 
30 traffic regulation or as to whether the intersection has a 
name is recorded as the node attribute, tables like an 
Intersection regulation table and intersection name table 
are separately generated to record the Infomnation, 
though they are not explained In this embodlment. 
35 [0118] The node coordinates are infomnation which 
represents the coordinates In the longitude and latitude 
directions of the node recorded in the node record NR1 . 
While the absolute longitude and latitude coordinates 
may be recorded as the coordinates of the node in the 
40 longitude and latitude directions, they are usually repre- 
sented in a coordinate system in which the longitude and 
latitude widths of the area of the unit U are nomnalized 
with values of 2-bytes or so, on the basis of the lower 
left comer of the unit U (rectangular area) containing the 
45 recorded node. For example, as shown In Flg.29, with 
the lower left corner Na of the unit U represented by co- 
ordinates (OOOOh, OOOOh) (where h indicates a hexadec- 
imal value), the coordinate system of the unit U is nor- 
malized with 8000h In both of the longitude and latitude 
50 directions. In this case, the coordinates of the upper left 
comer Nb of the unit are represented as (OOOOh, 8000h). 
The coordinates of the lower right comer Nc of the unit 
are (8000h, OOOOh). The coordinates of the upper right 
comer Nd of the unit are (8000h, 8000h). 
55 [0119] The node connection Infomnation is infomna- 
tion Indicating the connection between the node N re- 
corded in the node record NR1 and a link L recorded In 
a link record LR described later. The node connection 
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Information will be fully described later. 
[0120] The Internal data structure of other node 
records NR2 to NR(Q+R) is not described herein be- 
cause It is the sanne as that of the node record NR1. 
However, note that the other node records NR2 to NR 
(Q+R) contain Information about different nodes N. 
[01 21 ] Next, the data structure of the first link table of 
Flg.7 is described. Note that the first and second link 
tables have the same data structure and they differ from 
each otlier In that they are respectively generated for 
highways and streets. Therefore the second link table 
is not described in detail below. Flg.30 Is a diagram 
showing the detailed data structure of the first link table. 
In Fig.30, the first llnktable contains the number of roads 
S and M road records RR1 to RRM. The number of 
roads S is Infomiatlon which shows the number of roads 
contained In the road network expressed by the first 
node table. S Is a natural number of 1 or larger, which 
shows how many roads exist In the road network on the 
map represented by the unit U. One road attribute is al- 
lotted to the road record RR1 ; information about links L 
and nodes N having this same road attribute is recorded 
in the road record RR1. Another road, attribute Is as- 
signed to the road record RR2 and information about 
links L and nodes N having this same road attribute is 
recorded in the road rocord RR2. Similarly, one road at- 
tribute which has not been assigned to other road 
records RR1 to RR(S-1) is assigned to the road record 
RRS, and Infomnation about links L and nodes N having 
this same road attribute is recorded therein. Different 
road attributes are thus assigned to the road records 
RR1 to RRS. The road attribute is infomnation for clas- 
sifying the roads by type. Typically, the roads are clas- 
sified into freeway, national road, prefectural road, city 
road, private road, etc, which are further classified by 
name. If necessary, Infomnation about one-way traffic 
regulation, etc., may be adopted as the road attribute. 
[0122] The road record RR1 contains the road at- 
tribute, the number of links T1 the starting node record 
number, and T1 link records LR1 to LRT1 . The road at- 
tribute is Infomriation which shows the road type (free- 
way, national road, prefectural road etc.), one-way reg- 
ulation, etc. The number of links T1 is information indi- 
cating the number of links L recorded In the road record 
RR1 . T1 is a natural number of 1 or larger, which shows 
how many links L of the road attribute Information exist 
In the road network on the map of the unit U. The starting 
node record number is the node record number which 
specifies a given node record N R. As explained referring 
to Flg.28, etc., the node record numbers specify where 
the node record NR2 and others are recorded, counted 
from the first node record NR1 numbered "0." The afore- 
mentioned certain node record NR Is the record which 
contains the node N located at the beginning of the road 
. network expressed by the road record RR1. The link 
record LR1 contains Infonmation about one of the links 
L classified by the road attribute in the road network on 
the map of the unit U. The link record LR1 contains link 



attribute and link connection information. The link at- 
tribute is infonmation indicating the attribute of the link L 
expressed by the link record LR1 . The link attribute typ- 
ically Includes the link type (main link, side link, etc.) or 

5 the number of lanes. The link connection information is 
infonnation about a node(s) N connected to the link(s) 
L of the link record LR1 , or about a link L connected to 
the link L of the link record LRI through the node(s) N. 
The link record LR2 contains information about another 

10 one of the links L classified by the road attribute. Simi- 
larly, the link record LRT1 contains infonnation about 
one link L among the links L classified by the road at- 
tribute which has not been recorded in other link records 
LR(T1 -1 ). Like the link record LR1 , the link records LR2 

IS to LRT also contain the link attribute and link connection 
infonmation. Infonmation about different links L are thus 
recorded In the link records LR1 to LRTTI. 
[01 23] Next, a specific example of the infomnation re- 
corded in the first link table Is described about the road 

20 network of Flg.26. As stated above, the road network of 
Rg.26 contains the 11 nodes NO to NIG and the 11 links 
LO to L1 0. For clear description, It is assumed that the 
links LO to L2 are connected in the order of L0->L1->L2 
to form one road (e.g. a national road) starting from the 

25 node NO. Under this assumption, the links LO to L2 have 
the same road attribute (national road). It Is also as- 
sumed that the links L3 to L5 are connected In the order 
of L3-»L4->L5 to form one road (e.g. a prefectural road) 
starting from the node N4. Under this assumption, the 

30 links L3 to L5 have the same road attribute (prefectural 
road). It is also assumed that the links L6 to L8 are con- 
nected in the order of L6-^L7->L8 to fonm one road (e. 
g. a private road having a width of 5.5 meters or larger) 
starting from the node N7. Under this assumption, the 

35 links L6 to L8 have the same road attribute (private 
road). It is also assumed that the links L9 and L10 are 
connected in the order of L9-^L1 0 to forni one road (e. 
g. a city road) starting from the node N5. Under this as- 
sumption, the links L9 and L10 have the same road at- 

40 tribute (city road). 

[0124] Under these assumptions, there are four 
roads, i.e. national road, prefectural road, private road 
and city road, so that "4" is recorded as the number of 
roads, S, in the first link table. For the road attribute, 

45 since there are four kinds of roads, I.e. national road, 
prefectural road, private road and city road, four road 
records RR1 to RR4 are recorded in the first link table. 
The road record RR1 is described first. Infomnation rep- 
resenting "national road" Is recorded as its road at- 

50 tribute. For the number of links T1 , information showing 
"3" is recorded since the national road Is formed with the 
links LO to L2. The starting point of the road of the links 
LO to L2 Is represented by the node NO. The node NO 
has the record number "1" (see Fig.28). Therefore "1" 

55 Is recorded as the number of the starting node N. Next, 
In the link record LR11 (the record of the link LO), the 
link attribute is not explained here. 
[0125] The link connection infonmation recorded in 
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each link record LR and the node connection informa- 
tion shown in Fig.27 are now described. At the same 
time, operation of tracing the connection between the 
nodes N and links L will be described. For example, in 
Flg.26, the node N2 is connected with the four links L1 , 
L2. L6 and L7, The four links L1 , L2, L6 and L7 are thus 
connected with each other at the node N2. The infomna- 
tion about the node N2 is recorded in the node record 
NR10 (see Fig.27). Information pieces about the links 
L1 , L2. L6 and L7 are recorded in the link records LR12, 
LR13, LR31 and LR32, respectively (see Fig.31). Infor- 
mation for tracing the links L1 , L2, L6 and L7 connected 
to the node N2 is recorded in the node connection infor- 
mation In the node record NR10 (see Fig.27) and In the 
link connection infomriation in the link records LR12, 
LR13, LR31 and LR32 (see Fig.31). First, infomnatlon 
for enabling reference to the link record LR12 In which 
the first link L connected to the node N2 (it is assumed 
to be the link L1) is recorded in the node record NR10 
as the node connection information. More specifically, 
the node connection Information may be the offset ad- 
dress from the beginning of the link table to the link 
record LR12, or it may be the link record number of the 
link record LR12. Now, the link record numbers are num- 
bers which specify where the link record LR1 2 and oth- 
ers are recorded in the link table, counted from the first 
link record LR11 numbered "0." When the link record 
numbers are assigned to the link records LR of Fig.31 , 
the link record numbers "0" to "3" are assigned to the 
link records LRU to LR13. The link record numbers "4" 
to "6" are assigned to the link records LR21 to LR23. 
The link record numbers '•7" to "9" are assigned to the 
link records LR31 to LR33. Further, the link record num- 
bers 10 and 11 are assigned to the link records LR41 
and LR42. 

[01 26] Now, it should be noted that the offset address 
and link record number are recorded in the node con- 
nection information only when the road network is traced 
within the same unit U. Similarly, for the link connection 
infomnation, the offset address and node record number 
are referred to only when the road network is traced 
within the same unit U. The offset address and the link 
record are not refen^ed to in a process where the con- 
nection Is traced in a road network extending over a 
boundary between a unit U and a neighboring unit NU, 
whicii will be fully described later referring to Flgs.37 and 
38. 

[0127] In the example of Fig.32, the node connection 
infomnation in the node record NR1 0 contains the offset 
address to the link record LR12 or the link record 
number of the link record LR12, so that the link record 
LR12 in the link table can be referred to from the node 
record NR10. Also, in the example of Flg.32, since the 
link record LR32 isrefen'ed to from the link record LR12, 
the offset address to the link record LR32 or the link 
record number of the link record LR32 is recorded in the 
link connection Infomriation in the link record LR12, so 
as to enable reference to the link. L6 connected to the 



link LI . The node connection Information In the node 
record NR10 and the link connection information in the 
link record LR1 2 show that the link LI is connected with 
the link L6 at the node N2. 
5 [0128] Now, it should be noted thatthe link connection 
inforimation of the link record LR1 2 contains a flag which 
shows that this link connection infomnation is related to 
another link L, as well as the link record number or offset 
address. 

10 [01 29] It should also be noted that the link connection 
Infomnation for reference to a link L recorded in the same 
road record RR is not recorded in the link record LR. 
This is because links L belonging to the same road 
record RR can be traced on the basis of the arrange- 

15 ment of the link records LR, without the need to refer to 
the link connection information. That Is to say, the link 
record LR11 and the link record LR12 are recorded In 
the successive address regions in the road record RR1 , 
which shows that the link LI and the link L2 are connect- 

20 ed with each other. SImilariy, in the road record RR3, 
the link records LR31 and LR32 are recorded in the suc- 
cessive address regions, which shows thatthe link L6 
and the link L7 are connected with each other. 
[0130] The link L6 recorded in the link record LR31 , 

25 which is referred to next to the link record LR12, is not 
connected to any link L other than those in the road 
record RR1 . Therefore the link connection information 
about the link record LR32 contains infomnation that al- 
lows reference to the node record NR1 0 where the node 

30 N2 at the center among the links LI , L2, L6 and L7 is 
recorded. The offset address to the node record NR10 
or the node record number of the node record NR1 0 is 
used as the link connection infomnation of the link record 
LR32: 

35 [0131] It should be noted that the link connection in- 
formation in the link record LR32 contains a flag which 
shows that the link connection information is set to the 
node table NR, as well as the node record number or 
offset address of the node record NR10. 

40 [0132] As described above, each node record NR on- 
ly contains the node connection information to a link L 
connected to it first; each link record LR contains the link 
connection infomnation to a link L which is connected to 
the link L recorded therein and belongs to another road 

45 record RR, or it contains the link connection Information 
to a node record NR where the staiting node N is re- 
corded. It is thus possible to trace the connection of links 
L starting from each node N. 

50 (Data Structure of the Unit Header) 

[0133] Referring to Fig .7 again, the data structure of 
the unit header is now described in detail. The unit hiaad- 
er contains management information about the unit data 
55 in the cartographic file CF. The unit header at least in- 
cludes the unit ID, the version code, and the data sizes 
of the eight kinds of tables contained in the unit data. 
The unit ID is an Identification number which uniquely 
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specifies the unit U represented by the cartographic file 
CF. More specifically, the unit ID is a number which iden- 
tifies the level L of the unit U and the parent-child relation 
and neighboring relation of the unit U, which is prefera- 
bly mutually convertible with the path name of the car- ^ 
tographic file CF. For example, when the unit ID is ex- 
pressed by a 32-bit (4-byte) code, the two bits from the 
MSB are used as reserved bits, which are followed by 
the unit level L in 2 bits, 5-bit sectional position X3 In the 
longitude direction at the level "3", 5-blt sectional posi- 
tion Y3 in the latitude direction at the level "3", 3-btt sec- 
tional position X2 in the longitude direction at the level 
"2", 3-bit sectional position Y2 in the latitude direction at 
the level "2", 3-blt sectional position X1 in the longitude 
direction at the level "1**, 3-blt sectional position Y1 in 
the latitude direction at the level "1**, 3-bit sectional po- 
sition XO In the longitude direction at the level "0", and 
3-bit sectional position YO in the latitude direction at the 
level "0". The sectional position X3 in the longitude di- 
rection at the level "3" is a number which shows the po- 
sition of the unit U counted In the east longitude direction 
(starting from longitude 0"*) when the unit U belongs to 
the level "3". The sectional position Y3 in the latitude 
direction at the level "3" is a number which shows the 
position of the unit U counted in the north latitude direc- 
tion (starting from latitude 0** N) when the unit U belongs 
to the level "3". The sectional position X2 in the longitude 
direction at the level "2" is a number which shows the 
position of the unit U counted in the east longitude di- 
rection (starting from the lower left comer of the unit U 
at the level "3") when the unit U belongs to the level "2". 
The sectional position Y2 in the latitude direction at the 
level "2" is a number which shows the position of the 
unit U counted in the north latitude direction (starting 
from the lower left corner of the unit U at the level "3") 
when the unit U belongs to the level "2". The sectional 
position XI in the longitude direction at the level "1" is 
a number which shows the position of the unit U counted 
in the east longitude direction (starting from the lower 
left corner of the unit U at the level "2") when the unit U 
belongs to the level "1 The sectional position Y1 in the 
latitude direction at the level "1" is a number which 
shows the position of the unit U counted in the north lat- 
itude direction (starting from the lower left comer of the 
unit U at the level "2") when .the unit U belongs to the 
level "V. The sectional position XO In the longitude di- 
rection at the level "0" is a number which shows the po- 
sition of the unit U counted in the east longitude direction 
(starting from the lower left comer of the unit U at the 
level "1") when the unit U belongs to the level "0". The 
sectional position YO in the lat'rtude direction at the level 
"0" is a number which shows the position of the unit U 
counted in the north latitude direction (starting from the 
lower left comer of the unit U at the level "1 '*) when the 
unit U belongs to the level "0". 

[0134] For example, since the unit Uq at the level "0" 
shown in Fig .4 has the path name 
"¥MAP¥D1 606¥D0401 ¥D0603¥M0201 .map." L=0. 



X3=16. Y3=6, X2=4. Y2=1, X1=5, Y1=3, X0=2 and 
Y0=1. In this case, the unit ID of the unit Uq is 
135928529 (in decimal). As Is clear, the unit ID can be 
uniquely specified from the path name of the carto- 
graphicf lie CF, and the path name can be uniquely spec- 
ified from the unit ID. 

[0135] The version code is an identification code that 
represents the version of the cartographic file CF (unit 
U). The version code is, for example, represented by a 
4-byte code where the format version of the unit is ex- 
pressed as a 2-byte code and the contents version of 
the unit Is expressed as a 2-byte code. For example, 
when a cartographic file CF having a certain unit ID Is 
downloaded from the center station 2 Into the terminal 
device 1 , this version code is used to decide whether to 
substitute It for a cartographic file CF of the same unit 
ID already stored In the first storage device 19 of the 
terminal device 1 . This process will be described in de- 
tail later. 

[0136] For the data size of each table, the data size 
of each table In the cartographic file CF Is recorded in 2 
bytes, for example. The offset address of each table 
from the beginning of the cartographic file CF can be 
calculated by sequentially adding the data sizes of the 
tables. The data sizes of the tables contain the data size 
of the basic background table, data size of the detailed 
background table, data size of the basic character/sym- 
bol table, data size of the detailed character/symbol ta- 
ble, data size of the first node table, data size of the first 
link table, data size of the second node table, and data 
size of the second link table. The contents of each table 
have been already described. 

[0137] The detailed data structure of the cartographic 
file CF has been described so far. Next, the operation 
in which the tenninal device 1 reads out the cartographic 
file CF from the first database 111 will be described re- 
ferring to the drawings. 

(Read Operation) 

[0138] As has been described referring to Fig.1, the 
tenninal device 1 of this embodiment is typically a car 
navigation system. As Is known, It executes operations 
like map matching, route search, route guide, etc. 
Among these operations, the route search operation Is 
now described In detail, which Includes the operation of 
reading out the cartographic files CF, the operation of 
tracing the connection of a road extending over a unit U 
and its neighboring unit NU, and the operation of asso- 
ciating nodes N and links L between different levels. In 
the following description, the process of finding the 
shortest route between starting and destination points 
is not specifically described, since it is not a point of this 
Invention. 

[0139] Fig. 33 is a diagram showing the concept of the 
route search operation. As shown in Fig. 33, the search 
is expanded from both of the starting point SP and the 
destination point DP to obtain the shortest route. The 



15 



20 



25 



30 



35 



40 



45 



SO 



22 



BNSOOCID: <EP. 



.1134674A1_L> 



43 



EP1 134 674A1 



44 



route search uses cartographic files CF at a plurality of 
levels from a lower level to a higher level. I n this process, 
in the vicinities of the starting point SP and the destina- 
tion point DP, the shortest route is searched for by using 
cartographic files CF at a lower level which show de- 
tailed road networks. In the area otherthan the vicinities 
of the starting point SP and the destination point DP, the 
search uses cartographic files CF at higher levels which 
show rough road networks. The route search shown in 
Flg.33 uses the so-called bidirectional interlevel search 
method. For example, the known Dijkstra method is 
used to find the shortest route from the starting point SP 
to the destination point DP by using the cartographic 
files CF. The Dijkstra method is not described any further 
herein because rt is not a point of this Invention and also 
because it is a known technique. 
[0140] Now, referring to the flowchart of Flg.34, the 
procedure of the bidirectional Interlevel search per- 
formed by the terminal device 1 is described in detail. In 
the bidirectional interlevel search, the terminal device 1 
first sets the starting point SP and the destination point 
DP (steps S101, 8102). In the steps 8101 and 8102, 
the user of the terminal device t operates the Input de- 
vice 11 according to a menu displayed on the display of 
the output device 110 to set the starting point SP and 
the destination point DP. In a recent car navigation sys- 
tem, the starting point SP and the destination point DP 
are generally set by using addresses, telephone nurr^ 
bers, names of places or facilities, etc. The infomnation 
specifying the starting point SP and the destination point 
DP is transferred from the input device 11 to the data 
processing portion 13. 

[0141] When the step SI 02 ends, the data processing 
portion 1 3 cooperates with the read/write cohti-ol portion 

18 to sequentially read out cartographic files CF re- 
quired In the route search frorn the first storage device 

1 9 Into a main storage not shown (step 81 03). As al- 
ready stated referring to Flg.2, etc., the cartographic 
files CF stored in the first storage device 1 9 are digital 
data generated about individual units U defined by di- 
viding a map into rectangular areas. Each cartographic 
file CF is managed by the file system. The file system 
generates directories in such a manner that the logic re- 
gions in the first storage device 1 9 form a tree structure. 
The logic region where a cartographic file CF Is stored 
can thus be uniquely specified by the path Including the 
root, file name, and names of subdirectories Interposed 
between them. As described above, the tree structure 
and the file names of this embodiment specify the par- 
ent-child relation and neighboring relation among the 
units U. In the first step 8103, in order to read out, from 
the first storage device 19, the cartographic file CF 
showing the vicinity of the starting point SP transferred 
from the input device 1 1 , the data processing portion 13 
and the read/write control portion 1 8 forming the file sys- 
tem have to find Its path name. 

[01 42] Fig.35 is a flowchart showing the detailed pro- 
cedure of the step 8103 of Fig. 34. The process of Fig. 



35 can be summarized as follows: the data processing 
portion 13 finds the path name of the cartographic file 
CF on the basis of the level (hierarchical levet) of the 
target cartographic file CF and the coordinate Infomna- 

5 tlon about a representative point. On the basis of the 
path name found by the data processing portion 1 3, the 
read/write control portion 1 8 reads out the cartographic 
file CF from the first storage device 19. Now, referring 
to the flowchart of Rg.36, the procedure for reading out 

10 the cartographic file CF representing the unit Uq at the 
level "0" shown in Figs.4 and 5 ("¥IVI0201 .map") is de- 
scribed. 

[0143] The representative point Is a point whu^h is 
contained in the area the target cartographic file CF cov- 

15 ers. In the description below, the longitude coordinate 
LONq and the latitude coordinate LATq are coordinates 
which show the position of the representative point of 
the unit Uq in the longitude and latitude directions, re- 
spectively. In this embodiment, the longitude coordinate 

20 LONq and the latitude coordinate LATq are respectively 
assumed to be east longitude 132 degrees 39 minutes 
20 seconds and north latitude 32 degrees 55 minutes 
37 seconds. 

[0144] The process of the step 81 03 further requires 

25 some parameters. In the description below, the longi- 
tude width W3 indicates the length of the side extending 
along the longitude direction of the rectangular area 
which a level-"3" unit U covers. The latitude width H3 
Indicates the length of the side extending along the lat- 

30 itude direction of the rectangular area which a level-"3" 
unit U covers. In this embodiment, when each rectan- 
gular area at the level "3" is about 640 kilometers square 
as has been described referring to Figs.2 and 3, the lon- 
gitude width W3 and the ratltude wldth-^H3 are 28800 

35 seconds (8 degrees) and 1 9200 seconds (5 degrees 20 
minutes), respectively. The longitude width W2 shows 
the length of the side extending along the longitude di- 
rection of the rectangular area which a unit U belonging 
to the level "2" covers. The latitude width H2 Is the length 

40 of the side extending along the latitude direction of the 
rectangular area which a unit U belonging to the level 
"2" covers. When the rectangular area at the level "2" Is 
about 80 kilometers square, the longitude width W2 and 
the latitude width H2 are 3600 seconds (1 degree) and 

45 2400 seconds (40 minutes), respectively. The longitude 
width W1 shows the length of the side extending along 
the longitude direction of the rectangular area which a 
unit U belonging to the level "1" covers. The latitude 
width HI shows the length of the side extending along 

so the latitude direction of the rectangular area which a unit 
U belonging to the level "1 " covers. When the rectangu^ 
lar area at the level "1" Is about 10 kilometers square, 
the longitude width W1 and the latitude width HI are 450 
seconds (7 minutes 30 seconds) and 300 seconds (5 

55 minutes), respectively. The longitude width WO shows 
the length of the side extending along the longitude di- 
rection of the rectangular area which a unit U belonging 
to the level "O" covers. The latitude width HO shows the 
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length of the side extending along the latitude direction 
of the rectangular area which a unit U belonging to the 
level "0" covers. When the rectangular area at the level 
"0" is about 1.2 kilometers square, the longitude width 
WO and the latitude width HO are 56.25 seconds and 
37.5 seconds, respectively. 

[0145] The data processing portion 13 first specifies 
the longitude coordinate LONq and the latitude LATq of 
the representative point (step S201) and specifies the 
level L of the cartographic file CF to be read (L=0 when 
reading out the cartographic file CF of the unit Uq: step 
S202). The steps S201 and S202 are not described in 
detail here since they are common operations per- 
fomied in the bidirectional interlevel search. 
[01 46] Next, the data processing portion 1 3 moves to 
the step S203 and divides the longitude coordinate 
LONq of the representative point by the longitude width 
W3 at the level "3" to obtain the quotient DLON3, and 
divides the latitude LATo of the representative point by 
the longitude width W3 at the level "3" to obtain the quo- 
tient DLON3. Now, the longitude width W3=28800 sec- 
onds (8 degrees), the latitude width H3=1 9200 seconds 
(5 degrees 20 minutes), the longitude coordinate LONq 
- east longitude 132 degrees 39 minutes 20 seconds, 
and the latitude coordinate I^Tq = north latitude 32 de- 
grees 55 minutes and 37 seconds, so that the quotient 
DLON3=16 and the quotient DI-AT3=6. The data 
processing portion 13 arranges the calculated quotients 
DLON3 and DLAT3 to fomn a 4-digit number. The 4-diglt 
number obtained this time is "1606." When the quotient 
DLON3 and/or quotient DLAT3 have only one digit, "0" 
is added in the second digit. 

[0147] The data processing portion 13 adds the direc- 
tory identifier and the file name initiaF at the be- 
ginning of the generated 4-digit number and also adds 
the file name extension ".map" at its end. The data 
processing portion 1 3 thus finds the file name of the tar- 
get cartographic file CF (which contains the unit Uq) from 
the longitude coordinate LONq and the latitude coordi- 
nate LATq of the representative point (the file name is 
"¥M1606.map" in this case). 

[0148] Also, the data processing portion 13 adds the 
directory identifier "¥" and the subdirectory name initial 
"D" at the beginning of the generated 4-diglt nunnber. 
The data processing portion 13 thus derives the subdi- 
rectory name where the target cartographic file CF Is 
stored ("¥D1 606" in this case) from the longitude coor- 
dinate LONq and the latitude coordinate LATq of the rep- 
resentative point (step S203). 

[0149] Next, the data processing portion 13 checks 
whetherthe level L specified in the step S202 is the level 
"3" (step S204). When the level L is 3, the data process- 
ing portion 13 moves to the step S205 and attaches the 
file name derived in the step S203 ("¥i\41 606.map") after 
the root ("¥MAP") to derive the path name. The path 
name is thus "¥MAP¥M 1606. map. The data processing 
portion 13 outputs the derived path name to the read/ 
write control portion 1 8 (step S205). The read/write con- 



trol portion 18 reads out the cartographic file CF from 
the first database 111 in the first storage device 19 ac- 
cording to the input path name ("¥MAP¥M1606.map"). 
The read/write control portion 18 transfers this carto- 

5 graphic file CF to the main storage (not shown) in the 
data processing portion 13. The data processing portion 
13 has thus read out the cartographic file CF from the 
first storage device 1 9 into the main storage (step S206). 
[0150] Now, since the step S202 specified the level 

10 "0" as stated above, the data processing portion 1 3 de- 
cides In the step S204 that the level L Is not 3 and it 
moves to the step S207. The data processing portion 
13 calculates the remainder RLON3 of the quotient 
DLON3 derived In the step S203 and then divides the 

IS remainder RLON3 by the level-''2" longitude width W2 
to obtain the quotient DLON2. The data processing por- 
tion 13 further calculates the remainder RLAr3 of the 
quotient DI_AT3 derived In the step S203 and then di- 
vides the remainder RLAT3 by the level^"2" latitude 

20 width H2 to obtain the quotient DI_AT2. Now, when the 
quotients DLON2 and DLAT2 are obtained by using the 
values shown above, then DLON2=4 and DI_AT2=1. 
The data processing portion 13 then arranges the cal- 
culated quotients DLON2 and DLAT2 to fonrt a 4-digit 

2s number. The 4-digit number formed this time Is "0401 ." 
When the quotient DLON2 and/or quotient DLAT2 have 
only one digit, "0" is added in the second digit. 
[01 51 ] The data processing portion 1 3 adds the direc- 
tory identifier "¥" and the file name initial "M" at the be- 

30 ginning of this 4-digit number and also adds the file 
name extension ".map" to the end thereof. The data 
processing portion 13 thus derives the file name of the 
target cartographic file CF ("¥M0401 .map" In this case) 
from the longitude coordinate LONq and the latitude co- 

55 ordinate LATq of the representative point. 

[0152] Also, the data processing portion 13 adds the 
directory identifier "¥" and the subdirectory name initial 
"D" at the beginning of the generated 4-digit number. 
The data processing portion 13 thus derives the subdi- 

40 rectory name where the target cartographic file CF 
(which contains the unit Uq) is stored ("¥D0401" in this 
case) from the longitude coordinate LONq and the lati- 
tude coordinate LATq of the representative point (step 
S207). 

^ [0153] Next, the data processing portion 13 checks 
whetherthe level L specified in the step S202 Is the level 
"2" (step S208). When the level L is "2", the data 
processing portion 13 moves to the step S205 and at- 
taches the subdirectory name ("¥D1 606") derived in the 

50 step S203 and the file name derived in the step S207 
("¥IVI0401 .map") after the root ("¥MAP") to derive the 
path name. The path name is thus 
"¥MAP¥D1606¥I^0401 .map." the data processing por- 
tion 13 outputs the derived path name to the read/write 

55 control portion 18 (step S209). The read/write control 
portion 18 reads out the cartographic file CF from the 
first database 111 in the first storage device 19 accord- 
ing to the Input path name ("¥MAP¥1 606¥M0401 .map"). 
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The read/write control portion 1 8 transfers the read car- 
tographic file CF to the main storage (not shown) In the 
data processing portion 1 3. The data processing portion 
13 has thus read out the cartographic file CF from the 
first storage device 1 9 into the main storage (step S206). 
[0154] Now, since the step S202 specified the level 
"0" as stated above, the data processing portion 13 de- 
cides in the step S208 that the level L is not "2" and it 
moves to the step S2010. The data processing portion 
13 calculates the remainder RLON2 of the quotient 
DLON2 derived in the step S207 and then divides the 
remainder RL0N2 by the level-T longitude width W1 
to calculate the quotient DLON1 . The data processing 
portion 13 also calculates the remainder RLAT2 of the 
quotient DLAr2 derived in the step S207 and then di- 
vides the remainder R1_AT2 by the level-"1" latitude 
width H1 to obtain the quotient DI_AT1 . Now, when the 
quotients DLON1 and DLATI are obtained by using the 
values shown above, then DLON1=:5 and DLAT1=:3. 
The data processing portion 13 then arranges the cal- 
culated quotients DLON1 and DLAT1 to form a 4-digit 
number. The 4-digit number formed this time is "0503." 
When the quotient DLON1 and/or quotient DI_AT1 have 
only one digit, "0" is added in the second digit. 
[0155] The data processing portion 1 3 adds the direc- 
tory identifier "¥" and the file name initial "M" at the be- 
ginning of the generated 4-digit number and also adds 
the file name extension ".map" at its end. The data 
processing portion 13 thus derives the file name of the 
target cartographic file CF ("¥l\fl0503.map") from the lon- 
gitude coordinate LONq and the latitude coordinate 
LATq of the representative point. 
[0156] Also, the data processing portion 13 adds the 
directory idenllfier arid the subdirectory harne initial 
"D" at the beginning of the generated 4-digit number 
The data processing portion 13 thus derives the subdi- 
rectory name where the target cartographic file CF 
(which contains the unit Uq) is stored ("¥D0503" in this 
case) from the longitude coordinate LONq and the lati- 
tude coordinate LATq of the representative point (step 
S2010). 

[0157] Next, the data processing portion 13 checks 
whetherthe level L specified in the step S202 is the level 
"1" (step S2011). When the level L is "1", the data 
processing portion 13 moves to the step S2012 and at- 
taches, after the root ("¥MAP"), the subdirectory name 
("¥□1606") derived In the step S203, the subdirectory 
name ("¥D401") derived in the step S207, and the file 
name derived in the step S201 0 ("¥M0503.map") to de- 
rive the path name. The path name is thus 
"¥MAP¥D1 608¥D0401 3¥M0503.map." The data 
processing portion 13 outputs the derived path name to 
the read/write control portion 1 8 (step S201 2). The read/ 
write control portion 1 8 reads out the cartographic file 
CF from the first database 1 1 1 in the first storage device 
19 according to the input path name 
("¥MAP¥D1606¥D0401¥M0503.map"). The read/Write 
control portion 1 8 transfers the read cartographic file CF 



to the main storage (not shown) in the data processing 
portion 1 3. The data processing portion 1 3 has thus read 
out the cartographic file CF from the first storage device 
19 into the main storage (step S206). 

5 [0158] Now, since the step S202 specified the level 
*'0" as stated above, the data processing portion 1 3 de- 
cides In the step S2011 that the level L Is not 1 and it 
therefore moves to the step S201 0. the data processing 
portion 13 calculates the remainder RLON1 of the quo- . 

10 tient DLON1 derived in the step S201 0 and then divides 
the remainder RLON1 by the level-"0" longitude width 
WO to obtain the quotient DLONO. The data processing 
portion 13 also calculates the remainder RLATI of the 
quotient DI_AT1 derived in the step S2010 and then di- 

is vides the remainder RLATI by the level-^O" latitude 
width HO to obtain the quotient DLATO. Now, when the 
quotient DLONO and the quotient DI_ATO are obtained 
by using the values shown above, then DLON0=2 and 
DLAT0=1 . The data processing portion 13 then arrang- 

20 es the calculated quotients DLONO and DLATO to form 
a 4-digit number. The 4-digit number generated this time 
is "0201." When the quotient DLONO and/or quotient 
DLATO have only one digit, "0" is added in the second 
digit. 

25 [01 59] The data processing portion 1 3 adds the direc- 
tory identifier "¥*' and the file name initial "M" at the be- 
ginning of the generated 4-digit number and also adds 
the file name extension ".map" at its end. The data 
processing portion 1 3 thus finds the file name of the tar- 

30 get cartographic file CF ("¥M0201.map" in this case) 
from the longitude coordinate LONq and the latitude co- 
ordinate l_ATo of the representative point (step S2013). 
In the step S2013, it is automatically decided that the 
level L Is the lowest level "0", so that the data processing 

35 portion 1 3 does not derive the subdirectory name. 
[01 60] Next, the data processing portion 1 3 moves to 
the step S2014 and derives the path name by attaching, 
after the root ("¥I\^AP"), the string of subdirectory names 
derived in the steps S203, S207 and S2010 

40 ("¥D1606¥D401¥D0503") and the file name derived in 
the step S2013 ("¥IV!0201 .map" in this case). The path 
name is thus 

"¥I\/IAP¥D1 606¥D0401¥D0503¥M0201 .map." The data 
processing portion 13 outputs the derived path name to 

45 the read/write control portion 1 8 (step S201 4), The read/ 
write control portion 18 reads out the cartographic file 
CF f rom the first database 1 1 1 in the first storage device 
19 according to the input path name 
("¥MAP¥D1606¥D0401¥M0503.map"). The read/write 

50 control portion 1 8 transfers the read cartographic file CF 
to the main storage (not shown) in the data processing 
portion 13. The data processing portion 1 3 has thus read 
out the desired cartographic file CF (data for displaying 
the map of the unit Uq) from the first storage device 19 

55 into the main storage (step S206). 

[01 61 ] After the step S206, the data processing potion 
13 exits from the flowchart of Flg.35 and nrioves to the 
step SI 04 of Fig.34. The data processing portion 1 3 per- 
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forms the route search from the starting point SP by us- 
ing the cartographic file CF read into the main storage 
(step S1 04). It should be noted that the Dijkstra method 
is not described in detail herein since It Is a known tech- 
nique. Briefly, the Dijkstra method finds the shortest 5 
route by tracing the connection in the road network of 
the cartographic files CF. The procedure of tracing the 
connection of nodes N and links L in the cartographic 
files CF has already been described referring to Fig.32. 
[01 62] After the step S1 02, the data processing por- 
tion 13 executes the step S105 in parallel with the step 
S1 03. The data processing portion 13 reads out the car- 
tographic file CF showing the vicinity of the destination 
point DP set In the step SI 02 from the first storage de- 
vice 1 9 Into Its Intemal main storage not shown (step 
SI 05). The data processing portion 13 then perfomis 
the route search on the side of the destination point DP 
by using the cartographic file CF read In the step 8105 
(step S1 06). The processes In the steps S 1 05 and 31 06 
are not described In detail here since they are similar to 
the steps 81 03 and step 81 04. 

[0163] After the steps SI 04 and SI 06, the data 
processing portion 13 checks whether a condition has 
been satisfied to end the search at the level of the car- 
tographic files CF used In the steps SI 04 and 8106 
(step 8107). In the step 8107, whether the search con- 
dition has been met Is decided generally on the basis of 
whether the number of read cartographic files CF or the 
number of searched nodes N has reached a given value. 
When the step SI 07 decides that the condition for end- 
ing the search has not been satisfied, the data process- 
ing portion 13 returns to the steps S103 and SI 05 to 
read out cartographic files CF which adjoin the carto- 
graphic files CF already read during the search process 
from the starting point SP and the destination point DP. 
Now, when an already read cartographic file CF repre- 
sents the map of a unit U, the neighboring cartographic 
file CF represents the map of a neighboring unit NU (see 
Fig. 26). The data processing portion 13 finds the longi- 
tude coordinate LON and the latitude coordinate LAT of 
a new representative point and derives the path name 
of the neighboring cartographic file CF, and reads out 
the cartographic file CF specified by the path name into 
the main storage from the first storage device 19. 
[0164] Asshown In Fig .36, the position of the new rep- 
resentative point for defining the neighboring unit NU 
depends on through which neighboring node on the unit 
boundary the link L in the road network is connected to 
a link L in the neighboring unit NU (see Fig.26 for de- 
tails). More specifically, the link L11 of Fig.36 is connect- 
ed to a link L In the neighboring unit NU1 through the 
neighboring node N12 located on the upper side of the 
boundary (rectangle) of the unit U. Therefore the latitude 
width H of the level L to which the unit U belongs is add- 
ed to the latitude coordinate l-AT of the representative 
point P of the unit U to obtain the latitude coordinate 
LAT1 , and the point at this value is defined as the new 
representation point PI. 



[0165] Also, the link LI 2 of Ftg.36 Is connected to a 
link L In the neighboring unit NU2 through the neighbor- 
ing node N13 located on the right side of the boundary 
(rectangle) of the unit U. Therefore the longitude width 
W at the level L to which the unit U belongs is added to 
the longitude coordinate LON of the representative point 
P of the unit U to obtain the longitude coordinate LON2 
and the point at this value is defined as the new repre- 
sentative point P2. 

[0166] When performing the process of the steps 
8103 and 8105 In the second time or later, on the basis 
of the new representative points obtained as described 
referring to Flg.36, the data processing portion 13 reads 
out the cartographic files CF which represent the maps 
In the areas containing these representative points. This 
process Is carried out as described above, tn the next 
steps SI 04 and 8106, the data processing portion 13 
performs the search by using the cartographic files CP 
read in the steps S103 and SI 05. This search process 
is a process of tracing the connection of the road net- 
work from the cartographic file CF read last time Into 
that read this time, I.e. over the boundary between the 
unit U and the neighboring unit NU. 
[0167] By the way, in the techniques described in 
Background Art, the neighboring node records in each 
cartographic file contain numbers or offset addresses 
etc. which specify the neighboring nodes In the neigh- 
boring unit NU so that the connection of the road net- 
work can be traced even if It extends over the boundary 
between the unit U and the neighboring unit NU. How- 
ever, when such Information as is related to the intemal 
data structure of the cartographic file Is recorded in the 
unit, the numbers or offset addresses may be changed 
when the cartographic file representing the neighboring 
unit NU has been updated. This causes the problem that 
updating one cartographic file may require updating ail 
cartographic files which represent the neighboring units 
NU around it. According to this embodiment, to solve 
this problem, infomnation which is directly related to the 
internal data structure of the neighboring units NU is not 
recorded In the cartographic files CF; the data process- 
ing portion 1 3 executes the process of tracing to a neigh- 
boring node N in a neighboring unit NU by using the co- 
ordinate infomatlon about the nodes N and/or the at- 
tribute Information about the links L. 
[01 68] Now, the process in which the data processing 
portion 1 3 traces the connection of a road network over 
the boundaries between a unit U and its neighboring 
units NU In the steps 81 04 or 81 06 of Fig.34 wilj be fully 
described referring to Figs.37 and 38. Fig.37 shows a 
road network formed with four adjacent units U1 to U4. 
The road network contained in the unit U1 includes four 
nodes N1 0 to N 1 3 and three links LI 0 to LI 2. In the unit 
U1, the three nodes N10, N12 and N13 (refer to • 
marks) are neighboring nodes which are located on the 
boundary of the unit U1 . The road networic contained in 
the unit U2 includes five nodes N20 to N24 and fourlinks 
L20 to L23. In the unit U2. the four nodes N20 and N22 
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to 24 (refer to # marks) are neighboring nodes which 
are located on the boundary of the unit U2. The road 
network contained in the unit U3 is fomned of four nodes 
N30 to N33 and three links L30 to L32. In the unit U3. 
the nodes N30, N32 and N33 (refer to # nnarks) are 
neighboring nodes which are located oh the boundary 
of the unit U3. The road network contained in the unit 
U4 is formed of four nodes N40 to N43 and three links 
L40 to L42. The three nodes N40 to N43 (refer to # 
marks) are neighboring nodes which are located on the 
boundary of the unit U4. 

[0169] In Fig.37, the nodes N13 and N20 are connect- 
ed to each other, the nodes N12 and N30 are connected 
to each other, the nodes N24 and N43 are connected to 
each other, and the nodes N33 and N40 are connected 
to each other, thus fomiing one road network. 
[0170] In the road network of Fig.37, the link L12 Is 
connected to the link L20 via the neighboring nodes N 1 3 
and N20. As stated above, In the route search process, 
the data processing portion 13 sequentially reads out 
cartographic files CP expressing the neighboring units 
NU and expands the search towards the destination 
point DP or starting point SP. Therefore the data 
processing portion 13 has to trace the connection be- 
tween two links L over the boundary between a unit U 
and its neighboring unit NU. Thus, first, the data 
processing portion 13 searches the cartographic file CP 
of the unit U (i .e. the unit U1) contained in the main stor- 
age (more specifically, the link records RR: see Pigs. 30 
and 31 ) and extracts the link attribute of the link LI 2 ex- 
tending from the unit U1 into the unit U2 (Fig.38: step 
S301 ). The link LI 2 extending to reach the boundary of 
the unit U1 is referred to as an exit link LI 2 hereinafter. 
[0171] Next, the data processing portion 1 3 refers to 
the connection infomnation of the exit link L12 (a node 
record number or offset address) and searches for the 
node record NR of the neighboring node N1 3 connected 
to the exit link L12 (see Pig.27) from the cartographic 
file CP (more specifically, theflrst or second node table). 
Subsequently, the data processing portion 13 extracts 
the node coordinates of the neighboring node N13 from 
this node record NR (step S302). The neighboring node 
N13 connected to the exit link L12 is refenred to as exit 
node N13 hereinafter. 

[0172] Next, the data processing portion 1 3 refers to 
the cartographic file CP of the neighboring unit NU (i.e. 
the unit N2) contained In the main storage and extracts 
the node coordinates, one set at a time (more specifi- 
cally, it reads the node coordinates from the first or sec- 
ond node table: step S303). The data processing portion 
13 then calculates the difference between the node co- 
ordinates of the exit node N1 3 extracted in the step S302 
and the node coordinates extracted in the step S303 and 
checks whether the difference exceeds a given thresh- 
old (step S304). As has been described referring to Pig. 
29, the node coordinates are recorded as normalized 
values in this embodiment. The given threshold is pref- 
erably set around 1 to 2, though it depends on the width 



of the normalized coordinates. The data processing por- 
tion 13 repeats the steps S303 and S304 until the con- 
dition of the step S304 has been satisfied. Note that, 
each time it executes the step S303, the data processing 

5 portion 13 extracts node coordinates which have not 
been extracted before. Now, when the condition of the 
step S304 is satisfied, the node N having the node co- 
ordinates extracted In the step S303 represents the 
same position as the exit node N13. That is to say, the 

10 control portion 13 can find the neighboring node N20 
which is located at approximately the same position as 
the exit node N13 by repeating the steps S303 and 
S304. The neighboring node N20 thus found is refenred 
to as an entry node hereinafter. 

15 [0173] In the step S303, generally, the node coordi- 
nates are sequentially extracted one set at a time ac- 
cording to the order of the node record numbers (see 
Rg.28). In this embodiment, as has been described re- 
ferring to Pigs.26 and 28, the node records NR of the 

20 neighboring nodes N precede the node records NR of 
the non-neighboring nodes N in theflrst or second node 
record. This allows the data processing portion 1 3 to find 
the entry node without extracting the node coordinates 
from the node records NR of the non-neighboring nodes 

25 N. This minimizes the load of the data processing por- 
tion 13 when it searches for the entry node. That is to 
say, the data processing portion 13 can find the entry 
node without fail by retrieving as many node records NR 
as the neighboring nodes from the beginning of the first 

30 or second node table; that is. it does not have to retrieve 
all node records NR from the first or second node table 
recorded in the cartographic file CP of the neighboring 
unit NU. In this way, the arrangement of the node 
records NR of this 6mt)6dtment cohtributes also to the 

35 speeding up of the entry node search, 

[0174] As described referring to Pig.26, the neighbor- 
ing node records NR are an^anged according to the pref- 
erence order: the left side of the unit U (rectangle)->up- 
per side-->right side->lower side. Further, the node 

40 records NR of the neighboring nodes located on the left 
and right sides are arranged in ascending order of lati- 
tudes and those on the upper and lower sides are ar- 
ranged In ascending order of longitudes. The non-neigh- 
boring node records NR are first arranged in the ascend- 

45 ing order of latitudes and non-neighboring node records 
NR having the same latitude coordinate are arranged In 
the ascending order of longitudes. This anrangement 
further speeds up the processing of retrieving the entry 
node. For example, according to the arrangement rules 

so above, the node records NR of the neighboring nodes 
N10 to N20 of Rg.39 are recorded in the cartographic 
file CP of the unit U1 in the order of 
N1 0^N1 1 -^N1 2->N1 3->N1 4-^N1 5->N1 6-^N1 7^N1 8 
-^N19^N20. Similariy, the node records NR of the 

55 neighboring nodes N20 to N27 in the node table U2 are 
recorded in the cartographic file CP of the unit U2 In the 
order of 
N20->N21^N22->N23-*N24->N25->N26-^N27. Pur- 
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ther, in the cartographic file CF of the unit US, the node 
records NR are recorded in the order of 
N30->N31->N32^N33-^N34-^N35->N36^N37-»N38 

[01 75] In the route search process, usually, when the s 
search Is proceeded in a read cartographic file CF and 
the route being traced reaches a neighboring node, that 
neighboring unit NU Is newly read out. In this embodi- 
ment, when the cartographic file CF of the neighboring 
unit NU Is read out, all neighboring nodes on the bound- 
ary between the units are associated with each other 
between the previously read cartographic file CF and 
the currently read cartographic file CF. In this process, 
the fact that the neighboring node records NR are re- 
corded in the above-described order In the node tables 
speeds up the neighboring node associating process. 
For example, If the search has found the neighboring 
node N35 of the unit U3 which represents the same po- 
sition as the neighboring node N12 of the unit U1 , then 
the neighboring node N36 of the unit 3 which corre- 
sponds to the next neighboring node N13 of the unit 1 
is always located in the record next to N35. Similarly, if 
the search has found the neighboring node N16 of the 
unit U1 which corresponds to the neighboring node N20 
of the unit 2, then the neighboring node N17 of the unit 
1 which corresponds to the next neighboring node N21 
of the unit 2 is always located in the record next to N1 6. 
In this way, arranging the neighboring nodes according 
to the above-described rules speeds up the process of 
retrieving the neighboring nodes between the neighbor- 
ing units. 

[0176] When the data processing portion 13 has 
found the entry node in the step S304, It refers to the 
connection information (the node record number or off- 
set address) of the entry node N20 and searches the 
cartographic file CF of the unit U2 (more specifically the 
first or second link table) to find the link record LR of the 
link L20 connected to the entry node N20 (see Figs.30 
and 31). The link L20 connected to the entry node N20 
Is referred to as entry link L20 hereinafter. The data 
processing portion 13 then extracts the attribute infor- 
mation about the entry link L20 from the link record LR 
thus found (step S305). 

[0177] Next, the data processing portion 13 checks 
whether the attribute Infonnatlon about the exit link LI 2 
extracted In the step S301 Is the same as the attribute 
infonnation about the entry link L20 extracted in the step 
S305 (step S306). If the two pieces of attribute infomna- 
tlon differ, the data processing portion 13 returns to the 
step S303 to search for a new entry node N. In this em- 
bodiment, as has been explained referring to Fig.2, the 
first storage device 19 contains some cartographic files 
CF which represent maps on different scales. A carto- 
graphic file CF at a lower level shows a detailed road 
network; hence, when a difference between two sets of 
node coordinates is equal to or lower than a given 
threshold, it is relatively more likely that the two nodes 
N represent the same position. However, a cartographic 



file CF at a higher level shows only a rough road net- 
work; therefore, even II the difference between two sets 
of node coordinates do not exceed the given threshold, 
it is relatively less likely that the two nodes N represent 
the same position. In this embodiment, the step S306 
checks whether the attributes of the exit link and the en- 
try link agree/disagree with each other so that the data 
processing portion 1 3 can correctly trace the same road, 
i.e. so that it will not trace from one road to a different 
road. That Is to say, the process of the step S306 can 
be omitted when the cartographic files CF belong to a 
lower level. 

[0178] When the data processing portion 13 decides 
in the step S306 that the attribute infonnation about the 
exit link LI 2 and that of the entry link L20 agree with 
each other. It recognizes that it Is correctly tracing one 
road and exits from the flowchart of Rg.38 and moves 
to the step SI 07 of Flg.34. When the data processing 
portion 13 decides that the condition has been satisfied 
to end the search at the level the cartographic files CF 
read this time belorig to, It checks whetherthe routef rom 
the starting point SP and the route from the destination 
point DP have been connected (step SI 08). When the 
routes from the starting point SP and the destination 
point DP have been connected with each other, the data 
processing portion 13 decides that it has found the 
shortest route between the two points and ends the 
route search process. On the other hand, when the 
routes from the starting and destination points SP and 
DP have not been connected yet. the data processing 
portion 13 goes to the step 8109, where It moves to the 
next higher level and continues the route search by us- 
ing cartographic files CF showing larger areas and 
rougher road networks. 

[01 79] Next, the process of moving from a lower level 
to a higher level is described in detail. In this process, 
the data processing portion 13 moves from a node N 
where the search at the lower level ended (the end of 
the route being traced) to a node N whteh shows the 
same position in a cartographic file CF at a higher level, 
it Is therefore necessary that all nodes N contained In 
the higher-level cartographic file CF can be retrieved 
from the nodes N in the child unit CU so that the data 
processing portion 13 can certainly move to the higher 
level. 

[01 80] In orderto realize such retrieval. In convention- 
al methods, the node records contained node numbers, 
offset addresses, etc. of the higher-level nodes N which 
represent the same positions as the nodes N at the low- 
er level. However, when the lower-level cartographbfile 
contains such information as Is related to the intemal 
data structure of the higher-level cartographic file, up- 
dating the higher-level cartographic file requires updat- 
ing the lower-level cartographic file so that the process 
of moving from the lower to higher level can be smoothly 
achieved. Accordingly, In this embodiment, the carto- 
graphic files CF do not contain any Infonnation which Is 
directly related to the Internal data structure of hlgher- 
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level cartographic files CF; the process of changing lev- 
els is achieved by referring to the node coordinate infor- 
mation and the link attribute infomnation. In this case, 
however, a higher-level cartographic file CF generally 
has lower coordinate resolution than a map expressed 
by a lower-level cartographic file CF. Therefore, as 
shown In Fig.40, between lower-level and high-level car- 
tographic files CF, two nodes N having different coordi- 
nates may be represented by the same coordinates be- 
cause of a rounding error produced at the higher level. 
Hence the higher-level node N corresponding to the low- 
er-level node N cannot be uniquely specified with the 
node coordinates only. 

[0181] Accordingly, this embodiment utilizes not only 
the node coordinates but also the order (arrangement) 
in which the node records NR are recorded. That is, in 
the first or second node table, the node records NR of 
both of the neighboring and non-neighboring nodes are 
arranged according to the clearly defined rules. Accord- 
ingly, even If a higher-level unit U has rounding errors 
in coordinates, the node records NR are recorded in the 
ascending orders of coordinates on the basis of the nor- 
malized longitude/latitude coordinates which do not 
contain the rounding errors. Accordingly, when the data 
processing portion 13 traces from a lower-level node N 
to a node N which is contained also in the parent unit 
PN and represents the same position, it can uniquely 
specify the corresponding node N In the parent unit PU 
according to the order of the node records NR, from 
among the nodes N which are recorded in the lower- 
level unit U and also in the parent unit U and which will 
be located at the same coordinates because of the 
rounding en-or on the higher level. 
[0liB2i More specifically, among the cartograpKic flies 
CF, as already stated, a parent file PU has longitudinal 
and latitudinal unit widths eight times larger than those 
of Its child unit CU at the level immediately below. On 
the other hand, regardless of the level, each node has 
normalized coordinates which are normalized with 
8000h (16 bits) both in the longitude and latitude direc- 
tions of the unit U. That is to say, the coordinate resolu- 
tion of the parent unit PU is 1/8 of that of the child unit 
CU both in the longitude and latitude directions. There- 
fore, if nodes N in the child unit CU have the same upper 
13 bits In their normalized 16-blt longitude and latitude 
coordinates, they will have the sarne normalized coor- 
dinates in the parent unit PU. 

[01 83] For example, as shown in Fig.41 , suppose that 
the five nodes Na, Nb, Nc, Nd and Ne recorded in the 
child unit CU have the same upper 13 bits in their nor- 
malized 16-bit longitude and latitude coordinates and 
that the four nodes Na, Nc, Ndand Ne respectively have 
their parent nodes Na2, .Nc2, Nd2 and Ne2 recorded in 
the parent unit PU (each node record NR has a flag or 
code showing the presence of Its parent node UP). In 
this case, in the n ode table of the child unit CU , as shown 
in Fig.42. the five node records NR of the nodes Na, Nb, 
Nc, Nd and Ne are recorded In the order of Na-^N- 



b_>Nc->Nd->Ne accordingto the order of ascending lat- 
itudes and longitudes (as already explained). Note that 
the five node records NR of the nodes Na, Nb, Nc, Nd 
and Ne are not necessarily successively recorded In the 

5 node table. 

[0184] When the node table of the parent unit PU is 
generated, the node records NR of the parent nodes 
Na2. Nc2, Nd2 and Ne2, respectively corresponding to 
the nodes Na, Nc, Nd and Ne, are recorded In this order 

10 on the basis of the arrangement of the five node records 
NR (they are not necessarily recorded In successive po- 
sitions). As a result, the parent node Nd2 in the parent 
unit PU can be Identified for the node Nd recorded in the 
child unit CU as follows. First, in the node table, among 

15 the nodes N which have the same upper 1 3 bits in their 
16-bit nonnalized coordinates and have their parent 
nodes N, the node Nd in the child unit CU Is recorded 
In the third node record NR. Next, the normalized coor- 
dinates in the parent unit PU are calculated from the nor- 

20 malized coordinates of the node Nd in the child unit CU. 
Next, the node table of the parent unit PU is searched 
and the nodes N having the calculated normalized co- 
ordinates are found. As a result, in the example shown 
in Flgs.41 and 42, the four nodes Na2, Nc2, Nd2 and 

25 Ne2 are detected. Next, since the parent node Nd cor- 
responding to the node Nd in the child unit CU must be 
recorded in the third position among these four nodes 
Na2. Nc2, Nd2 and Ne2. it is known that the parent node 
of the node Nd Is the node Nd2. 

30 [01 85] After having moved to the higher level, the data 
processing portion 13 repeats the steps SI 03 to SI 08 
at that level and ends the route search when the search- 
es from the starting point SP and the destination point 
DP have been cohriectied. 

35 [01 86] In this way, the cartographic data of this inven- 
tion is filed in units divided in rectangular areas and the 
Individual units do not contain any record numbers, 
record addresses, etc. which are related to the internal 
data structure of other units, both between neighboring 

40 units at the same level and between parent and child 
units at different levels; this allows the cartographic data 
to be flexibly updated by replacing a unit file represent- 
ing an arbitrary area at an arbitrary level: 

45 (Process of Transmitting/Receiving the Cartographic 
Files CF) 

[0187] Recently, systems in which the center station 
2 provides maps to the terminal device 1 are being stud- 
io led and developed. Such systems allow the terminal de- 
vice 1 to extract a required map on demand. Therefore 
the second database 25 in the second storage device 
24 of the center station 2 is generally larger In scale than 
the first database 111 in the terminal device 1. In this 
55 ernbodiment, the aforementioned file systems manage 
somecartographicfilesCFInthefirstdatabaselll and 
the second database 25. The center station 2 and the 
terminal device 1 transmit/receive the cartographic files 
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CF as described below. 

[01 88] First, the terminal device 1 requests the center 
station 2 to transmit a cartographic file CF. Flg.43(a) Is 
a flowchart showing the procedure in which the terminal 
device 1 requests the center station 2 to transmit a cer- s 
tain cartographic file CF. Fig.43(b) is a diagram showing 
the format of the request REQ sent as control data 
through the procedure of Fig.43(a). When the user of 
the terminal device 1 wants to add a new cartographic 
file CF to the first storage device 19 or update an old 
cartographic file CF to a newer version, the user oper- 
ates the input device 1 1 to activate the map request/re- 
ceive function. Next, the user operates the input device 
1 1 according to a menu screen displayed on the display 
of the output devbe 11 0 to enter the area and the level 
(hierarchical level) of the desired map. In response to 
the input from the user, the Input device 11 outputs in- 
formation indicative of the map area and level to the data 
processing portion 13(step S401). Inthe process of en- 
tering the map area, the user may operate the input de- 
vice 11 to enclose the desired area with a rectangular 
region on a wide-area map displayed on the display, or 
may operate the input device 1 1 to specify the area by 
using an address index. 

[0189] Receiving the area and level information from 
the input device 11 , the data processing portion 13 con- 
verts the area information into longitude and latitude co- 
ordinates. The data processing portion 13 then outputs 
the longitude and latitude coordinates and the level in- 
fonnation to the request generating portion 14. The re- 
quest generating portion 14 generates a request REQ 
having the fonnat shown in Fig.43(b) by using the input 
longitude and latitude coordinates and level information 
(stepS402). In Fig.43(b>, the request REQ includes in- 
fomriation showing the level of the cartographic file CF 
the user requires and the longitude and latitude coordi- 
nates specifying the area of the map the cartographic 
file CF covers. More specifically, when the user specifies 
the area by enclosing it in a rectangular region on a 
wide-area map, the longitude and latitude coordinates 
are composed of Its lower left longitude coordinate, low- 
er left latitude coordinate, upper right longitude coordi- 
nate and upper right latitude coordinate. The request 
generating portion 14 then outputs the generated re- 
quest REQ to the first transmit/receive portion 15 and 
the first transmit/receive portion 15 sends out the Input 
request REQ onto the uplink UL through the antenna 16 
(step S403). 

[01 90] Next, the process in which the center station 2 
transmits the cartographic file CF is described. The re- 
quest REQ sent from the temiinai device 1 is received 
at the second transmit/receive portion 21 in the center 
station 2 through the uplink UL in the communication 
network 3. The second transmit/receive portion 21 out- 
puts the received request REQ to the received request 
analyzing portion 22. Fig. 44 is a flowchart showing the 
procedure which the center station 2 executes after re- 
ceiving the request REQ. The received request analyz- 



ing portion 22 analyzes the input request REQ and out- 
puts the analyzed results to the read control portion 23. 
The read control portion 23 searches the second data- 
base 25 for the cartographic file CF specified by the an- 
alyzed results (step S501). The request REQ contains 
the level (hierarchical level) of the cartographic file CF 
requested from the terminal device 1 and the lower left 
longitude coordinate, lower left latitude coordinate, up- 
per right longitude coordinate and upper right latitude 
coordinate of the map represented by that cartographic 
file CF. The received request analyzing portion 22 first 
extracts the lower left longitude and latitude coordinates 
from the request REQ and then derives the path name 
of the requested cartography file CF according to the 
procedure shown by the flowchart of Fig.35, during 
which it refers to the lower left longitude and latitude co- 
ordinates as the representative point. 
[0191] Next, the received request analyzing portion 
22 checks whether the cartographic file CF having the 
derived path name Is stored In the second storage de- 
vice 24 (step S502). When the cartographic file CF is 
absent, the center station 2 ends the process of Fig. 44. 
On the other hand, when the cartographic file CF is 
present, the read control portion 23 receives the path 
name derived by the received request analyzing portion 
22 and reads out the requested cartographic file CFfrom 
the second storage device 24 according to the path 
name. The read control portion 23 transfers the read 
cartographic file CF to a memory in the packet assem- 
bler 25. The packet assembler 25 then reads in the re- 
quested cartographic file CF (step S503). The packet 
assembler 25 assembles packets P on the basis of the 
read cartographic file CF (step S504) and outputs them 
to the second transmit/receive portion 21. The second 
transmit/receive portion 21 sends out the input packets 
P onto the downlink DL (step S505). The step S504 will 
be described in detail later. 

[0192] When the step S505 ends, in order to check 
whether the second database 25 contains a further car- 
tographic file CF which represents the area specified by 
the request REQ, the received request analyzing portion 
22 adds the longitude width W and the latitude width H 
at the level specified by the request REQ to the repre- 
sentative point coordinates previously specified In the 
step S501 and sets this value as a new representative 
point. The received request analyzing portion 22 then 
checks whether the longitude coordinate and the lati< 
tude coordinate of the new representative point exceed 
the upper right longitude coordinate and the upper right 
latitude coordinate specified by the request REQ. If the 
longitude and latitude coordinates of the new represent- 
ative point do not exceed the upper right longitude and 
latitude coordinates, the center station 2 then performs 
the steps 8502 to S505, where packets P are assem- 
bled on the basis of another cartographic file CF and 
transmitted to the terminal device 1 . When the longitude 
coordinate and the latitude coordinate of the new repre- 
sentative point exceed the upper right longitude coordi- 
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nate and the upper right latitude coordinate, the center 
station 2 recognizes that it has sent all requested carto- 
graphic files CF to the terminal device 1 and ends the 
process of Flg.44. 

[01 93] The center station 2 repeats the steps S501 to 5 
S505 to send to the terminal device 1 cartographic files 
CF representing the map of the level and area as re- 
quested from the temninal device 1 . 
[0194] Fig.45 shows the structure of data generated 
during the process in which the packets P are assem> 
bled from a cartographic file CF. When the step S503 
ends, the packet assembler 25 contains one carto- 
graphic file CF as shown in Flg.45(a). The packet as- 
sembler 25 executes the step S504. Flg.46 is a flowchart 
showing the detailed procedure of the step S504. Re- 
ferring to Figs.45 and 46, the operation of the packet 
assembler 25 Is described In detail. First, the packet as- 
sembler 25 generates master data MD on the basis of 
the cartographic file CF contained therein (step S601). 
As shown in Fig.45(b), the master data MD includes a 
data header DH and a data portion. Fig. 47 shows the 
detailed internal data structure of the master data MD. 
In Fig.47, the data header DH includes a unit ID and a 
version code. 

[0195] The unit ID is a code which specifies the car- 
tographic file CF on which the master data MD is based. 
The version code is a code which represents the fomiat 
version and contents version of the cartographic file CF 
on which the master data MD Is based. The unit ID and 
the version code are both stored in the unit header of 
the cartographic file CF (see Fig. 7); the packet assenri- 
bler 25 extracts them when it reads in the cartographic 
file CF and holds them. The unit ID and the version code 
are uised by the terminal device 1 as will li>e described 
later. 

[0196] The cartographic file CF Itself is set in the data 
portion of the master data MD. As already stated, the 
cartographic file CF Includes various kinds of tables (see 
Fig.7). These tables do not contain information which 
would be referred to by each other. In order words, the 
temnlnal device 1 can use each table independently. For 
example, as shown In Fig. 8(a), the terminal device 1 can 
display only the basic background table on the output 
device 110. That Is t6 say, each table has a separable 
data structure. Therefore the data portion may be 
fomied with only the basic data of the basic background 
table, basic character/symbol table, highway node table 
and highway link table (I.e. data which represents a 
schematic map). Alternatively, the data portion may be 
formed with only the detailed data of the detailed back- 
ground table, detailed character/symbol table, street 
node table and street link table. Part of the cartographic 
file CF may be set in the data portion In this way. 
[01 97] As shown in Fig.7, the unit header contains the 
unit ID and the version code. The unit ID and the version 
code are contained in the data header DH (see Fig .47). 
In this way, as the unit ID and the version code are set 
in the data portion of the master data MD, two unit IDs 



and two version codes are contained In the master data 
MD. Therefore this data portion do not necessarily have 
to contain the unit ID and the version code, 
[01 98] The packet assembler 25 divides the generat- 
ed master data MD into t pieces. As shown in Fig.45(c), 
I pieces of segment data SD1 to SDi are thus generated 
(step S602). In this step S602, the packet assembler 25 
does not consider the data header DH and the data por- 
tion (I.e. the cartographic file CF) contained in the mas- 
ter data MD, That Is to say, part of the data header DH 
and part of the data portion may be mixed in a piece of 
segment data SD. The 1 pieces of segment data SD are 
provided with numbers (which are referred to as seg- 
ment numbers hereinafter). These segment numbers 
are preferably serial numbers which do not overlap 
among the segment data pieces. This facilitates opera- 
tion of the terminal device 1 as will be described later. 
[01 99] The packet assembler 25 also attaches an er- 
ror correction code (or error detection code) to the i piec- 
es of segment data SD1 to SDi (step S603). As shown 
in Fig.45(d), i pieces of segment data (with error correc- 
tion code) SD1 to SDI are thus generated. The packet 
assembler 25 further dh/ides each piece of segment da- 
ta (with error connection code) SDI to SDi Into j pieces. 
Thus j packets are generated for each piece of the seg- 
ment data SD as shown in Fig. 45(e) (step S604). As a 
result, the packet assembler 25 generates a total of IxJ 
packets P11, P12 ... P1j ... Pij on the basis of one car- 
tographic file CRThe ixj packets P11, P12 ... P1j ... Pij 
are provided with numbers (referred to as packet num- 
bers hereinafter). The packet numbers are preferably 
senal numbers which do not overlap among the packets. 
This facilitates operation of the terminal device 1 as will 
be descr'ied later; The packet hUrfibers allow the temnl- 
nal device 1 to easily check whether the separately 
transmitted ixj packets P11, P12 ... P1j .., Pij are all 
present. When the step S604 ends, the packet assem- 
bler 25 exits from the subroutine of Fig.46 and retums 
to the process of Flg.44. It then performs the step S505. 
in the step S505, the packets P11 , P12 ... Pij ... Pij are 
sequentially sent from the second transmit/receive por- 
tion 21 onto the communication networks (downlink DL) 
to the temrilnal device 1 . 

[0200] Next, referring to the flowchart of Fig.48, the 
procedure In which the terminal device 1 receives the 
cartographic file CF will be described. The packets P1 1 , 
PI 2 ... Pij ... Pij sent from the center station 2 are in- 
putted to the antenna 16 of the terminal device 1 through 
the communication network 3. The first transmit/receive 
portion 1 5 sequentially receives the packets P1 1 , P1 2 . . . 
Pij ... Pij from the antenna 16 (step S701). The first 
transmit/receh/e portion 15 has a buffer memory not 
shown. The first transmit/receive portion 15 sequentially 
stores the received packets P11, PI 2 ... P1j ... Pij Into 
the buffer memory. 

[0201] The packet disassembler 17 periodically ac- 
cesses the buffer memory of the first transmit/receive 
portion 15 to check whetherthe ixj packets P11 , P12 ,.. 
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P1j ... Pij sent from the center station 2 have been all 
stored in the buffer memory (step S702). The check In 
the step S702 Is made on the basis of the packet num- 
bers attached to the packets P11, PI 2 ...Pij ... Pij. More 
specifically, when the packet numbers are serial num- 
bers, the packet disassembler 17 checks whether the 
packet numbers are all present from 1 to (ixj), 
[0202] If alt packets P are not present In the step 
S702, the packet disassembler 17 performs the step 
S701 again. Instead of moving to the step S703. As a 
result, the first transmit/receive portion 15 eventually re- 
ceives the lacking packets P. 

[0203] On the other hand, when the step S702 shows 
that all packets P are present, the packet assembler 25 
moves to the step S703. The packet disassembler 17 
disassembles the packets P1 1, P12... Pij... Pij re- 
ceived In the step S701 to make up the master data MD 
(step S703). The step S703 also effects the error cor- 
rection as needed. The disassembled master data MD 
Is outputted to the data processing portion 13. The data 
processing portion 1 3 generates the cartographic file CP 
on the basis of the input master data MD and stores the 
generated cartographic file CF into the first storage de- 
vice 1 9 in cooperation with the read/write control portion 
18 (step S704). 

[0204] After the step S704, the data processing por- 
tion 25 checks whether there still remains any series of 
packets P to be received (step S705). When there are 
packets P to be received, It returns to the step S701 to 
continuously receive the packets P. When there Is no 
more packets to be received, it ends the process of Fig. 
48. 

[0205] Fig.49 is a flowchart showing the detailed pro- 
cedure of the step S703 of Flg.48. Flg.50 shows the 
structure of data generated during the process in which 
the cartographic file CF Is generated from the packets 
P11, P12 ... Pij ... Pij. As is clear from the explanation 
above, when the step S703 of Flg.48 begins, the series 
of packets P11, PI 2... Pij... Pij are all present as 
shown In Rg.50(a) in the. first transmit/receive portion 
15. The packet disassembler 1 7 extracts the packets P 
to be processed from the packets P11 , P12 ... P1j ... Pij 
buffered in the first transmit/receive portion 15 (step 
S801). It is now assumed that the packet disassembler 
17 extracts the packets P 11, P12 ... PIJ. 
[0206] Next, the packet disassembler 1 7 removes the 
packet number from each packet P extracted in the istep 
S801. The packet disassembler 17 unites the packets 
P, from which the numbers have been removed," to re- 
store one piece of segment data SD as shown in Fig. 50 
(b) (step S802). Under the assumption above, the pack- 
ets P11, P12 ... P1j are combined together to restore the 
segment data SD1 . 

[0207] Each segment data SD has the en^or conrection 
code (or error detection code). After the step S802, by 
utilizing the error correction code, the packet disassem- 
bler 17 corrects errors possibly present in the restored 
segment data SD (with error correction code) (step 



S803). 

[0208] Next, the packet disassembler 1 7 removes the 
error correction code from the segment data SD(with er- 
ror correction code) and thereby restores the segment 

5 data SD (without error correction code) as shown in Fig. 
50(c) (step S804) . The restored segment data SD is held 
in the storage region In the packet disassembler 17. Un- 
der the assumption above, the segment data SD1 is er- 
ror-corrected and held In the storage region of the pack- 

10 et disassembler 1 7. 

[0209] After the step S804, the packet disassembler 
17 checks whether there still remain any packets P to 
be processed in the first transmit/receive portion 15 
(step S805). When there are packets P to be processed, 

'5 the packet disassembler 1 7 returns to the step S801 ; It 
carries out the steps S801 to S804 to restore the seg- 
ment data SD from the packets P as shown In Flg.50(a) 
to (c). In this description, at the beginning of the process 
of Flg.49, there are (ixj) packets P in the first transmit/ 

20 receive portion 1 5. Therefore the loop of the steps S701 
to S705 is repeated i times. As a result, the i pieces of 
segment data SD1 to SDi are restored. 
[0210] When this loop has been repeated a required 
number of times, no packets P to be processed are left 

25 in the first transmit/receive portion 15. When the deci- 
sion of the step S805 Is made in this condition, the pack- 
et disassembler 1 7 moves to the step S806. When all 
packets P have been processed, the 1 pieces of segment 
data SDI to SDi are being held in the packet disassem- 

30 bier 1 7. As stated above, the segment data SDI to SDi 
each have a segment number. The packet disassembler 
17 arranges the segment data SD1 to SDi in order ac- 
cording to the segment numbers, I.e. in the order of the 
serial segment numbers. Subsequently the segment 

35 numbers are removed from the segment data SDI to 
SDI. The packet disassembler 17 then unites together 
the segment data SD1 to SDI from which the segment 
numbers have been removed. The master data MD is 
thus restored as shown in Flg.50(d) (step S806). The 

40 restored master data MD is outputteid to the data 
processing portion 13 (step S807). 
[0211] Now, not only this map providing system but 
any communication system may encounter communica- 
tion troubles. Therefore the terminal device 1 cannot al- 

45 ways correctly restore all pieces of segment data SD. 
Correctly restored segment data SD Is segment data SD 
which Is identical to that the center station 2 generated. 
For example, suppose that the segment data SD2 was 
not correctly restored and other segment data SDI , SD3 

50 to SDi were correctly restored. In such a case, the pack- 
et disassembler 1 7 can correct the segment data SD2 
by using the error correction code attached to the seg- 
ment data SDI , SD3 to SDi. 

[0212] In response to Input of the master data MD, the 
55 data processing portion 13 starts the step S704. As al- 
ready stated, this step S704 includes the process of 
generating the cartographic file CFfrom the masterdata 
MD and the process of storing the generated carto- 
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graphic file CF in the first storage device 19. Flg.51 is a 
flowchart which shows the detailed procedure of the 
step S704 of Fig,48. 

[0213] First, the data processing portion 13 extracts 
the unit ID from the data header DH of the input master 
data MD (step S901). As stated above, the unit ID and 
the path name of the unit are convertible from each oth- 
er. The data processing portion 13 derives the path 
name of the cartographic file CF in the master data MD 
from the extracted unit ID. 

[021 4] The data processing portion 1 3 checks wheth- 
er a cartographic file CF having the path name derived 
in the step S902 is already stored in the first storage 
device 1 9 (step S903). If not, the data processing portion 
13 removes the data header DH from the master data 
MD and extracts the cartographic file CR Then the data 
processing portion 13 transfers the derived path name 
and the cartographic file CF which has been received 
this time to the read/write control portion 18. The read/ 
write control portion 18 stores the cartographic file CF 
received this time Into the first storage device 1 9 accord- 
ing to the transferred path name. The new cartographic 
file CF has thus been added to the first database 111 . 
[0215] On the other hand, when the step S903 shows 
that a cartographic file CF having the path name derived 
In the step S902 is already present in the first storage 
device 19, the process proceeds as below. In this case, 
the data processing portion 13 moves to the step S904 
and extracts the version code stored In the data header 
DH of the master data MD. Also, in cooperation with the 
read/write control portion 18. the data processing por- 
tion 1 3 reads out the cartographicf lie CF having the path 
name derived in the step S902 from the first storage de- 
vice 1 9. The data processing portion 1 3 extracts the ver-- 
sion code recorded in the unit header of the cartographic 
file CF read from the first storage device 19 and com- 
pares it with the version code extracted in the step S904. 
When the data processing portion 13 decides that the 
version code extracted from the master data MD is new- 
er, it moves to the step S906 to extract only the data 
portion of the master data MD and stores the newer- 
version cartographic file CF in the second storage de- 
vice 30. The old cartographic file CF in the first database 
111 has thus been updated to a newer version. 
[0216] On the other hand, when the cartographic file 
CF read from the first storage device 19 Is newer, the 
data processing portion 1 3 discards the received master 
data MD. That is to say, the cartographic file CF currently 
received is not stored into the first storage device 19. 
[0217] As described above, the cartographic files CF 
of this embodiment are generated as digital data in 
which maps on a plurality of scales are each sectioned 
into units. The region (logical region) where the carto- 
graphic files CF are stored Is represented by the path 
names which are specified in a tree structure represent- 
ing their parent-child relation and neighboring relation. 
The cartographic files CF are thus efficiently managed. 
Since each unit U does not contain any Infomnation re- 



lated to the data structure of other units, the plurality of 
units U are remotely related with each other. Therefore, 
even when one cartographic file CF has been updated, 
other cartographic files CF do not have to be updated. 

5 In this way, according to the cartographic files CF of this 
embodiment, it is very easy to newly store and update 
the cartographic files CF In the first storage device 19. 
[0218] When tracing the connection of a road networic 
extending over adjacent units U of the cartographic files 

10 CF, the data processing portion 1 3 refers to the coordi- 
nate information about an exit node and an entry node 
and/or the attribute inf omnatlon about an exit link and an 
entry link. That is to say, the data processing portion 13 
does not refer to infomnation which is related to the in- 

15 ternal data structure of the neighboring units NU, such 
as the record numbers or offset addresses of nodes N 
or links L recorded In the neighboring units NU. There- 
fore, even If one cartographic file CF In the first storage 
device 19 has been updated, the road network connec- 

20 tlon can be correctly traced between adjacent carto- 
graphic files CF, without the need to update the carto- 
graphic files CF of the neighboring units NU. 
[0219] In this embodiment, when the road networi< 
connection is traced over the boundary between a unit 

25 u and a neighboring unit NU, it is necessary to retrieve 
the entry node and entry link of the neighboring unit NU . 
In each unit U, the node records NR and the link records 
LR are arranged according to the predetermined rules. 
This speeds up the process of retrieving the entry node 

30 and the entry link. 

[0220] Furthermore. In the route search process of 
this embodiment, the data processing portion 13 has to 
find, from a node N at a lower level, a node N represent- 
ing the same position in^acartographicfile OF at a higher 

35 level. Also in this case, between the units U at the higher 
and lower levels, the child unit CU does not contain any 
infomnation related to the internal data structure of the 
parent unit PU, and the parent unit PU does not contain 
any information related to the Intemal data structure of 

40 the child unit CU; hence, even if only the cartographic 
file CF at the higher level has been updated, it is not 
necessaryto update the cartographte files CF which rep- 
resent its child units CU. 

[0221] Moreover, even when a partial area map, e.g. 

45 a unit U, has been updated to a new one, the data 
matching between neighboring units and between up- 
per and higher levels can be retained; when the center 
station 2 provides cartographic files CF through wire or 
by wireless to the terminal device 1 , it can send only a 

50 cartographic file CF the terminal, device 1 requires. This 
reduces the data transmission time and the communi- 
cation cost. 

[0222] This embodiment has described a car naviga- 
tion system as an example of the temiinal device 1 . 
55 However, this embodiment can be applied also to sys- 
tems in which a database of the cartographic files CF is 
created in a personal computer and the personal com- 
puter displays map or executes route search. That Is to 
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say, this embodiment can be applied not only to mobile 
temninal devices but also to stationary tenminal devices. 
[0223] With a stationary temninal device, the commu- 
nication network 3 does not have to be a vi/ireless trans- 
mission path but It can be wired. 
[0224] In this embodiment, the tennlnal device 1 
makes bidirectional communication with the center sta- 
tion 2 through the communication network 3 so as to 
inform the center station 2 of the area of a map the user 
requires and to receive the cartographic file CF of that 
area. However, the center station 2 may transmit the 
cartographic file CF to the terminal device 1 in a broad- 
casting manner. 

[0225] Further, in this embodiment, the first database 
111 and the second database 25 contain cartographic 
files CF having a four-level hierarchical structure Includ- 
ing levels "0" to "3". However, the cartographic files CF 
In the first database 111 and the second database 25 
may be generated at any number of levels; I.e. it Is not 
limited to the four-level structure. 
[0226] Moreover, In this embodiment, the map at each 
level is divided at equal intervals in the longitude and 
latitude directions to form the rectangular areas (units 
U). However, the map at each level may be divided at 
various intervals in the longitude and latitude directions 
In such a manner that the cartography files CF at each 
level contain an almost equal amount of data. However, 
it is necessary In this case that each cartographic file 
OF be provided with information which specifies the di- 
vision sizes in the longitude and latitude directions. 
[0227] Also, in this embodiment, one cartographic file 
CF is generated for one unit U. However, each carto- 
graphic file CF may be formed with a plurality of units U 
and management information for managing the plurality 
of units U. In this case, it Is desired that the number of 
units U collected in one cartographic file CF be limited 
to about 64 at most and that the management informa- 
tion for managing the collection of units U be simple, so 
that the cartographic files CF can be easily updated. 
[0228] in one cartographic file CF, the node records 
NR of the neighboring nodes may be recorded in an or- 
der tracing the boundary of the unit U in one direction. 
For example, suppose that the node records NR of the 
neighboring nodes are recorded in a clockwise order 
starting from the lower left corner of the unit U. Under 
this assumption, in the unit U1 of Rg.39, the node 
records NR of the neighboring nodes are recorded in 
the . order of: 

N1 0-^N11 -^N1 2-^N1 3-»N1 4^N15->N1 8-^N1 7 
->N16-^N20-^N19. Also, the node records NR of the 
neighboring nodes contained in the unit U3 are recorded 
as:N30-^N31^N32-^N34-^N33^ 
N38^N37-^N36^N35. Further, the node records NR 
of the neighboring nodes contained in the unit U2 are 
recorded as: N20^N21->N22^N23 

->N24-^N25->N27->N26. Now a specific example is 
described, whero the data processing portion 13 
searches forthe neighboring nodes N37 and N38 which 



correspond to the neighboring nodes N14 and N15. As 
stated above, in the cartographic file CF of the unit U1 , 
the node records NR of the neighboring nodes N14 and 
N15 are recorded In the order of N14->N1 5. In the car- 

5 tographic file CF of the unit U3, the node records NR of 
the neighboring nodes N37 and N38 are recorded in the 
order of N38-^N37. Then, when the data processing 
portion 13 has found the neighboring node N37 whk;h 
corresponds to the neighboring node N14,the neighbor- 

10 ing node corresponding to the neighboring node N1 5 is 
recorded in the position immediately preceding the node 
record NR of the neighboring node N37. The data 
processing portion 13 can thus quickly find the neigh- 
boring node corresponding to the neighboring node 

15 N 1 5. In this way, when the node records N R of the neigh- 
boring nodes are recorded In an order which follows 
along the boundary of the unit U , the neighboring nodes 
located on the boundary between the unit N and Its 
neighboring unit are successively arranged in reverse 

20 orders in their respective cartographic files CF, which 
allows the data processing portion 13 to quickly find a 
correspondence between a neighboring node of the unit 
and a neighboring node in the neighboring unit. 

25 (Second Embodiment) 

[0229] Fig.52 shows the structure of a map providing 
system according to a second embodiment of the inven- 
tion. This niap providing system contains a center sta- 

30 tion 101 and a terminal device 102. The center station 
101 and the temninal devbe 102 are connected trough 
a wireless transmission path 1 03. The wireless trans- 
mission path 103 at least contains a downlink from the 
center station 101 to the terminal.device 102. The center 

35 station 101 has a map server 1011 and an antenna 
1012. The map server 1011 Includes a first storage de- 
vice 1 01 3, a read control portion 1 01 4, a packet assem- 
bler 1015 and a transmitting portion 1016. The terminal 
device 102 is typically a car navigation system, which 

40 comprises an antenna 1021, a receiving portion 1022, 
a data processing portion 1 023 containing a packet dis- 
assembler 1024 and a file managing portion 1025, and 
a second storage device 1 026. 

[0230] Next, the structure of the center station 1 01 is 
45 described. The first storage device 1013 contains at 
least one cartographic file which can be provided to the 
terminal device 102. Details of the cartographic file CF 
will be described later. The first storage device 1013 is 
typically composed of a hard disk drive, CD-ROM drive 
so or DVD-ROM drive. 

[0231] The read control portion 1014, when required, 
reads part of the cartographic file CF from the first stor- 
age device 1 01 3 as cartographic data CD to be provided 
to the temninal device 1 02. The cartographic data CD 
55 will be described in detail later. The read cartographic 
data CD is outputted to the packet assembler 1015. 
[0232] The packet assembler 1 01 5 assembles pack- 
ets P on the basis of the input cartographic data CD. 
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Detailed operation of the packet assembler 1015 and 
the form of the packets P will be described later. The 
assembled packets P are outputted to the transmitting 
portion 1016. 

[0233] The transmitting portion 1 01 6 sends out the in- 
put packets P onto the wireless transmission path 1 03 
through the antenna 1012 and thereby the cartographic 
data CD is sent to the terminal device 1 02 as the packets 
P. The transmitting portion 1016 and the antenna 1012 
are typically realized with a mobile communication de- 
vice such as a mobile phone, or with a broadcasting de- 
vice for ground wave digital broadcast or satellite digital 
broadcast, for example. 

[0234] Next, the structure of the terminal device 1 02 
is. described. The receiving portion 1 022 receives the 
packets P sent from the center station 1 01 through the 
wireless transmission path 103. The antenna 1021 and 
the receiving portion 1022 are typically fomried with a 
mobile communication device such as a mobile phone 
or with a receiver device for ground wave digital broad- 
cast or satellite digital broadcast, for example. The re- 
ceiving portion 1022 outputs the received packets P to 
the packet disassembler 1024. 

[0235] The packet disassembler 1024 disassembles 
the input packets P to restore the cartography data CD. 
The restored cartographic data CD is outputted to the 
file managing portion 1025. 

[0236] The file managing portion 1 025 processes the 
input cartographic data CD according to a predeter- 
mined procedure. This procedure will be described later. 
This processing generates the cartographic file CF. The 
cartographb file CF has the same structure as the car- 
tographic file CF cartographic data in the center station 
1 01 . The cartographic file CF will be described In detail 
later. 

[0237] The second storage device 1 026 has a reada- 
ble and writable large-capacity storage medium. The 
second storage device 1 026 is typically composed of an 
HDD, DVD-RAM driving device. The cartographic file 
CF generated by the file managing portion 1 025 is writ- 
ten on this storage medium. As is known, the second 
storage device 1026 manages the storage region In 
clusters. 

[0238] While the data processing portion 1023 thus 
carries out the decoding and file management opera- 
tions, It also performs various other operations (e.g. 
route search, map matching and route guide). Further, 
as required, the data processing portion 1023 extracts 
part of a cartographic file CF in the second storage de- 
vice 1 026 and outputs It to an output device described 
later. Theterminal device 102 comprises an Input device 
and an output device as well as the components depict- 
ed in the drawing. However, these operations and the 
input and output devices are not described in detail 
herein and not shown in the drawings, since they are 
not main features of this invention. 
[0239] The input device and the output device are now 
only briefly described. The Input device is operated by 



a userof thetemninal device 102. Through the input de- 
vice, the user requests the terminal device 1 02 to scroll 
the map, to change the scale, etc. The output devtee is 
mainly composed of a display and a speaker. The dis- 

5 play displays a map as required. The display also dis- 
plays the results of route search or route guide carried 
out by the data processing portion 1023. The speaker 
provides the user, through speech, with the results of 
the route guide process perfonmed by the data process- 

10 Ing portion 1023. 

[0240] Next, referring to Flg.53, the structure of each 
cartographic file CF is described. First, as shown in Fig. 
53(a), a map a which covers a certain area is sectioned 
into MxN areas (M and N are arbitrary natural numbers) 

IS of a predetermined shape to fomn units XJq q to U|^-^ ^ 
(for convenience, the map Is sectioned in rectangular 
shape In this embodiment). The units Uq q to U,^.^ j^i.^ 
are processed Into data to fomn unit data UDqo to 
UD^.^^ N-1- '^^^ ""'t data UDq^o to UD(y/|.i ^.^ form part 

20 of unit records URo^oto UK^.^ ls|.i described later. A car- 
tographic file CF is generated on the basis of the units 
Uo.oto Um.i,n-i and stored in a given address region in 
the first storage device 1013. 

[0241] As shown in Flg.53(b), each cartographic file 

25 CF contains a file header FH. unit management infor- 
mation Mlg^n-. ""'t records URo,o to 
URm-i.n-1' "^h® header FH contains infomnation 
which specifies the area the cartographic file CF (map 
a) covers. More specifically, the file header FH includes 

30 the minimum longitude I-AT^in and latitude LON^^,n, the 
maximum longitude LAT^ax and latitude LONmax. the 
real distance Dlat in the longitude direction, and the real 
distance Dlon in the latitude direction. As shown in Fig. 
53(a), LATminv LONM,Ni LAT^ax ancl LON max indicate 

35 the minimum longitude, minimum latitude, maximum 
longitude and maximum latitude of the map a. As shown 
In Flg.53(a), Dlaj and D^qn indicate the real distances 
of the map a in the longitude and latitude directions. 
Thus LATi^iN, LONmin. LAT^ax. LONmax. ^ukt and 

40 Dlon define the area the cartographic file CF (i.e. the 
map a) covers. 

[0242] The unit manaigement infomnation Mly^iTCon- 
tains information for managing the unit records URq q to 
URm-i,n-i • ^^^^ specifically, the unit management Infor- 
ms mation IS/IIunit contains the number of unit records con- 
tained In the cartographic file CF, NOU, and offset val- 
ues XootoX|yj.^ jg_i of the unit records. NOU is the value 
MxN. The offset values X^oto X^^^^ jg.^ each represent 
the offset from the top address of the cartographic file 
50 CF (the position where it is stored In the first storage 
device 1 01 3) to the top address where the unit records 
URq 0 to URj^.i N-i are stored. Fig.53(b) shows, by way 
of example, the offset value Xq o o^the unit record URq^. 
[0243] The unit records URq q to UR^.^ ^-i are stored 
55 in the storage medium of the first storage device 1013 
on the basis of the addresses specified by the offset val- 
ues Xq to Xn-i in the unit management infomnation 
MluiNT* As shown In Fig.54. the unit records URqo to 
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URm-i.n-i contain the unit dataUoQto Uj^^^ ^j.^. The unit 
data Uo,o to U|yn are provided with their respective 
unit headers UH0.0 to UH^.i^ n.^. The unit records URo,o 
to URf^^.-i ^ are formed in this way. 
[0244] Now, to specifically explain each unit record 
UR, the unit record UR^j q is described as an exannple. 
First, as shown in Fig.53, the unit data UDq^o data 
which represents one of the areas sectioned in the map 
a; It Is real data which forms the map of the area which 
the corresponding unit Uq 0 represents. Now, for clear 
explanation, the map in the area represented by the unit 
Uq 0 <s relented to as a map po.o- More specifically, the 
unit data UDo,o includes bacl<ground data BDo,o* char- 
acter/symbol data COq.oi and road networtc data NDq^o 
about the map po.o- 

[0245] The background data BDq^o graphic data for 
displaying a river, railroad, green belt, buildings, bridg- 
es, etc. on the map po,0. As shown in Flg.54, the baclc- 
ground data BDq q is composed of a basic background 
data table BBDq^q ^ detailed background data table 
DBDq 0- As shown in Flg.55{a), the basic background 
data table BBDq^o contains graphic data for displaying 
basic elements (i.e. background) on the map p q q, such 
as a river, railroad, green belt, etc. As shown in Fig. 65 
(b), the detailed background data table DBDq 0 contains 
graphic data about buildings, bridges, etc. to display the 
basic background on the map Pq.o greater detail. 
[0246] As shown in Flg.54, the basic background data 
table BBDq Q and the detailed background data table 
DBDo,o have independent structures. Therefore the 
center station 101 and the terminal device 1 02 can sep- 
arate the basic background data table BBDq^o the 
detailed background data table DBDo,o and use them 
independently. That is to say, as shownj'n Fig 55(a), the 
terminal device 102 can display the basic background 
data table BBDo^o ^^one. Further, as shown in Fig.55(c), 
the temninal device 102 can superimpose the detailed 
background data table DBDq^o the basic background 
data table BBDq^o- 

[0247] The background of the map Pq.o '® fonned by 
superimposing the background displayed by the basic 
background data table BBDq^o that displayed by the 
detailed background data table DBDq^o- '^hat is, seen 
from a different aspect, the detailed background data 
table DBDo,o Is the differential data between the back- 
ground data BDq q and the basic background data table 
BBDo,o. 

[0248] The character/symbol data CDq q is data which 
represents character strings and/or map symbols on the 
map p 0,0. The character/symbol data CDo^o shows the 
names of places, roads, and facilities, map symbols, etc. 
on the map pQ q; As shown in Fig.54, the character/sym- 
bol data CDq 0 is composed of a basic character/symbol 
data table BCDq q and a detailed character/symbol data 
table DCDq o- As shown in Fig.56(a), the basic charac- 
ter/symbol data table BCDq^o contains basic data about 
the map po,0' ^^^^ ^s the names of places and roads, 
map symbols, etc. As shown in Fig.56(b). the detailed 



character/symbol data table DCDq o contains data re- 
quired to display the details of the map Po.o. such as the 
names of parks, railroads, bridges, factories, etc. 
[0249] As shown in Fig.54, the basic character/sym- 

5 bol data table BCDq q and the detailed character/symbol 
datatableDCDo^ohave independent structures. This al- 
lows the basic character/symbol data table BCDq^q and 
the detailed character/symbol data table DCDq.o to be 
used independently. That is to say, the terminal device 

10 102 can display the basic character/symbol data table 
BCDq^o alone as shown In Flg.56(a), or superimpose the 
detailed character/symbol data table DCDq q on the ba- 
sic character/symbol data table BCDq q as shown in Fig. 
56(c). 

15 [0250] The detailed character/symbol data table 
DCDq 0 is the differential data between the character/ 
symbol data CDq q and the basic character/symbol data 
table BCDq Q. 

[0251] The road network data NDq q is data which is 

20 used together with the background data BDq^o the 
character/symbol data CDq 0 to display roads on the 
map pQ 0- '1'his road network data NDq^q 's also used dur- 
ing the process of map matching, route search, or route 
guide. The road network data NDqo is composed of a 

25 highway network data table MNDq^q and a street net- 
work data table SNDq^q. As shown in Fig.57(a), the high- 
way network data table MNDq^q contains road network 
data about relatively wide roads (e.g. 5.5 meters or larg- 
er), i.e. road network data about highways. It is desired 

30 that, in the highway network data table M NDq,©. the road 
network data Is classified according to road type, such 
as freeway, general national road, prefecturai road, etc. 
As shown In Flg.57(b), the street network data table 
SNDq 0 contains road network data about relatively nar- 

35 row roads (e.g. between 3.0 and 5.5 meters), i.e. road 
network data about streets. 

[0252] Like the basic background data table BBDq^q 
and the detailed background data table DBDq 0. the 
highway network data table MNDq q and the street net- 

40 work data table SNDq^q have their respective independ- 
ent structures. Therefore, as shown in Fig.57(a)i the ter- 
minal device 1 02 can display only the highways by using 
the highway network data table MNDq^q alone. The ter- 
minal device 102 can also display, as shown in Fig. 57 

45 (b), only streets by using the street network data table 
SNDq 0 alone. Further, as shown In Flg.57(c), the termi- 
nal device 1 02 can also superimpose the street network 
data table SNDqq on the highway network data table 
MNDq 0 to display the highways and streets. 

so [0253] The street network data table SNDq^q 's the dif- 
ferential data between the road network data NDq q and 
the highway network data table MNDqq. 
[0254] During the map matching process etc., the ter- 
minal device 1 02 can use the highway network data ta- 

55 ble MNDq^o alone, or can use both of the highway net- 
work data table and the street network data table 
SNDo.0. 

[0255] The highway network data table MNDq q and 
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the street network data table SNDq^o are used also to 
trace the connection between a highway and a street 
A node representing the intersection of the highway and 
the street is used to trace such connection. 
[0256] As shown in Fig.58(a), the terminal device 1 02 
can generate a relatively rough map Po o by superim- 
posing the basic background data table BBDq o, the ba- 
sic character/symbol data table BCD0.0. and the high- 
way network data table MNDq^o- It can also generate a 
more detailed map Pg 0 as shown in Fig.58(b) by super- 
imposing the detailed background data table DEDq^o- 
the detailed character/symbol data table DCDq q, and 
the street network data table SNDq^q on the rough map 
Po,o shown In Fig.58(a). 

[0257] The detailed structure of the unit data UDq^o 
has thus been explained. Like the unit data UDq q, other 
unit data UDq^i ... UDo,n.i, UD^q. • UD^.^^n-i a'so 
have the structure described referring to Figs.54 to 58 
for their own areas. 

[0258] As already stated, the unit records URq^o ^o 
N-1 include the unit headers UHq q to UH)y|.^ fg.-]. 
The unit headers UHq q to UH^^.^ fg-., contain attribute 
information about the unit data UDq 0*0 UDjyi.., |sj.^-More 
specifically, for example, the unit header UHq q contains 
a unit ID which identifies the unit data UDq.o and the siz- 
es of the basic background data table BBDq^O' detailed 
background data table DBDq^o. I^aste character/symbol 
data table BCDq o, detailed character/symbol data table 
DCDq^o* highway network data table MNDq q and street 
network data table SNDq^o- Like the unit header UHq.o. 
other unit headers UH0.1 to UHm.i , n-i a^so contain the 
attribute information about the corresponding unit data 
UD0.1 to UD^.-i^ Any infonnation can be used as the 
unit IDs in the unit headers UHq^o to UHm-i. n-i > as long 
as it can specify the corresponding unit data UDqo to 
^I^M-LN-i' typical examples Include serial numbers, 
longitudes and latitudes, etc. 

[0259] Next, referring to the flowchart of Fig.59, the 
procedurein which the center station 101 sends the car- 
tographic data will be described. As already stated, the 
first storage device 1013 contains one or more carto- 
graphic files CF previously stored therein (see Figs.53 
and 54). When required, the read control portion 1014 
reads out part or the entirety of predetermined some car- 
tographic files CF from the first storage device 1013 
(step S1 001 ). In this embodiment, part of a cartographic 
file CF means the file header FH, the unit management 
infomnation Mlyi^^r. and some unit records UR in the car- 
tographic file CF. The entirety of a cartographic file CF 
means the file header FH, the unit management infor- 
mation Mlufyjn", and all unit records UR in the cartograph- 
ic file CF. In the description below, part or the entirety of 
a cartographic file CF read by the read control portion 

1014 Is referred to as cartographic data CD. The read 
cartographic data CD is loaded in the storage region 
(typically a RAM) in the packet assembler 1 01 5. 
[0260] After the step SI 001, the packet assembler 

1015 extracts Information required for transmission to 



the temnlnal device 1 02, i.e. the file header FH, the unit 
management infonnation MIunpt (se© Fig.53(b)) and 
one unit record UR (see Flg.53(b)) from the cartographic 
data CD baded in the internal storage region (step 
5 SI 002). 

[0261] The packet assembler 1015 assembles pack- 
ets P on the basis of the unit record UR, file header FH 
and unit management information Mlyi^n- extracted in 
the step 81002 (step SI 003). The step SI 003 will be 

10 described in detail later. The assembled packets P are 
outputted to the transmitting portion 1 01 6. The transmit- 
ting portion 1 01 6 sends out the input packets P onto the 
wireless transmission path 103 through the antenna 
1012 to transmit the jaackets P to the tenminal device 

15 102 (step 81004). 

[0262] After the step 81004, the packet assembler 
1015 checks whether there still remains any unit data 
UD to be transmitted in the cartographic data CD loaded 
In the internal storage region (step SI 005). When unit 

20 data UD to be transmitted still exists, the packet assem- 
bler 1015 i-eturns to the step SI 002 to extract the nec- 
essary data. On the other hand, when no unit data UD 
to be transmitted exists, the packet assembler 1015 In- 
forms the read control portion 1014 of this information. 

25 [0263] In response to the infonnation from the packet 
assembler 1015, the read control portion 1014 closes 
the cartographic data CD read in the step SI 001 (step 
S1006). Next, the read control portion 1014 checks 
whether there is cart:ographic data CD (a different piece 

30 from that closed In the step SI 006) which contains unit 
data UD to be sent to the temiinal device 102 (step 
81 007). When another piece of cartographic data CD is 
present, the read control portion 1014 returns to the step 
StOOl to read out the cartographte data CD. When no 

35 othercartographbdataCDexlsts,thecenterstation 101 
ends the series of processes shown in the flowchart of 
Flg.59. 

[0264] Fig.60 shows the structure of data generated 
during the process in which the packets P are generated 

40 from the cartographic data CD. 

[0265] When the step 81001 ends (see Fig.59), the 
read control portion 1014 contains the cartographic data 
CD as shown in Fig.61(a). When the step 81002 ends, 
the packet assembler 1 01 5 is holding the file header FH 

45 and some unit records UR. Flg.60(a) shows an example 
In which the unit record URq^o *s being held. The packet 
assembler 1 01 5 then carries out the step 81 003. Fig.61 
is a flowchart showing the detailed procedure of the step 
SI 003. Referring to Flg.61 , the operation of the packet 

so assembler 1 015 is now described In detail. First, master 
data MD Is generated on the basis of the file header FH, 
unit management information MluNiy and one unit 
record UR held In the packet assembler 1015 (step 
81101). The master data MD Is not generated directly 

55 from the cartographic file CF but is generated on the ba- 
sis of the one unit record UR held in the packet assem- 
bler 1015. With this generating method, even if an error 
occurs because of an external or internal factor In the 
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steps SI 001 to S1007 of Fig.59, the error affects only 
the one unit record UR. That is to say, this method pre- 
vents an errorfrom affecting the entire cartographic data 
CD. 

[0266] As shown in Rg.60(b), the master data MD is 
composed of a data header DH and a data portion. Fig. 
62 shows the detailed structure of the master data MD. 
In Fig. 61 , the data header DH includes a file ID, a unit 
ID and a unit size. 

[0267] The file ID Is a code which specifies the carto- 
graphic data CD on which the master data MD is based 
(i.e. the one which is currently loaded in the packet as- 
sembler 1015). An example of a method for generating 
this file ID is explained. The packet assembler 1015 
holds the file header FIH. As already stated, the file head- 
er FH contains the information which specifies the area 
the cartographic file CF (map a) covers (see Flg.63(b)). 
Therefore the file header FH can specify the cartograph- 
ic file CF, too. The packet assembler 1015 generates 
the file ID by using this file header FH. 
[0268] The unit ID is a code which specifies the unit 
record UR on which the master data MD is based (I.e. 
the one which was extracted In the step S1 002). When 
the step S1002 ends, the packet assembler 1015 is 
holding a unit record UR to be sent (see Fig.54). The 
packet assembler 1 01 5 extracts the unit ID from the unit 
record UR being held. The extracted unit ID is set in the 
data header DH. 

[0269] The two IDs and the unit size are used by the 
terminal device 1 02 as will be described later. 
[0270] The file header FH and the entirety or part of 
the data of the unit record UR are set In the data portion 
of the master data MD. The file header FH and the unit 
record UR thus.set are those held in the packet assem- 
bler 1 01 5. Now, as stated above, the unit record UR con- 
tains various tables (see Fig.54). These tables have 
structures which can be separated from each other. 
Therefore the data portion may be fomned with only the 
basic data of the basic background data table BBD, the 
basic character/symbol data table BCD, and the high- 
way network data table MND (i.e. data which represents 
a schematic map). The data portion may also be fomned 
with only the detailed data of the detailed background 
data table DBD, the detailed character/symbol data ta- 
ble DCD, and the street network data table SND. Part 
of the unit record UR may be set In this way. 
[0271] As shown in Fig.54, the unit header UH con- 
tains the unit ID. This unit ID Is contained in the data 
header DH (see Fig,62). Therefore, when the unit ID is 
set in the data portion of the master data MD, two unit 
IDs are contained in the master data MD. Hence the unit 
ID does not necessarily have to be contained in the data 
portion. 

[0272] The data size in the data header DH is the size 
of the data portion. It can be easily extracted since the 
sizes of the file header FH and the entire unit record UR 
are determined when the cartographic file CF is gener- 
ated in the first storage device 1013. When part of the 



unit record UR is set in the data portion, the size of the 
partial unit record UR is obtained on the basis of the 
sizes set in the corresponding unit header UH. 
[0273] The packet assembler 1015 divides the gener- 

5 ated master data MD Into I pieces. As shown in Fig. 60 
(c), the i pieces of segment data SD^ to SD| are thus 
generated (step S11 02). In this step S1 102, the packet 
assembler 1015 does not consider the data header DH 
and the data portion (i.e. the unit record UR) contained 

10 In the master data MD. That is to say, part of the data 
header DH and part of the data portion may be mixed 
in a piece of segment data SD. Numbers are assigned 
to the i pieces of segment data SD (referred to as seg- 
ment numbers hereinafter). The segment numbers are 

IS preferably serial numbers which do not overlap among 
the segment data pieces. This facilitates operation of the 
terminal device 102 as will be described later. 
[0274] The packet assembler 1 01 5 also attaches er- 
ror correction code (or error detection code) to the I plec- 

20 es of segment data SD^ to SD^ (step S1 1 03). As shown 
in Fig. 60(d), the I pieces of segment data (with error cor- 
rection code) SD^ to SD| are thus generated. The packet 
assembler 1015 further divides each piece of the seg- 
ment data (with error correction code) SD-, to SD| into j 

25 pieces. Then j packets are generated for each piece of 
the segment data SD as shown in Fig. 60(e) (step 
S1 104). As a result, the packet assembler 1015 has 
generated a total of ixj packets P^-,, P^g ^ij • ^ij °" 
the basis of one unit record UR extracted in the step 

30 SI 002. The ixj packets P^^, P^2 ••* ^ij ■■ provid- 
ed with numbers (referred to as packet numbers here- 
inafter). The packet numbers are preferably serial num- 
bers which do not overlap among the packets. This fa- 
cilitates operation of the temfiinaj device 102 as will be 

35 descried later. The packet numbers allow the terminal 
device 1 02 to easily check whether the separately trans- 
mitted Ixj packets P^^, P12 • • Pij — present. 
When the step S11 04 ends, the packet assembler 1 015 
exits from the subroutine of Fig. 61 and returns to the 

40 process of Fig.59. It then performs the step SI 004. In 
the step S1004, the packets P11, P12 ... P^j ... Pjj are 
sequentially sent from the transmitting portion 1 01 6 onto 
the wireless transmission path 1 03 through the antenna 
1012 to thetemninal device 102. 

45 [0275] Next, referring to the flowchart of Flg.63, the 
procedure in which the temninai device 1 02 receives the 
cartographic data will be described. The packets P^^, 
P-12 ... Pij ... Py sent from the center station are Inputted 
to the antenna 1021 of the terminal device 102 through 

50 the wireless transmission path 103. The receiving por- 
tion 1022 sequentially receives the packets P.|.|, P.|2 ... 
P.|j ... P|jOutputted from the antenna 1021 (stepS1201). 
The receiving portion 1022 has a buffer memory not 
shown. The receiving portion 1022 sequentially stores 

55 the received packets P^^, P^2 - ^ij ^ij ''^^^ buffer 
memory. 

[0276] The packet disassembler 1 024 periodically ac- 
cesses the buffer memory In the receiving portion 1 022 
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to check whether the i x j packets P^^, P^2 • • ^ij • 
sent from the center station 101 have been all stored In 
the buffer memory (step SI 202). The check in the step 
SI 202 is made on the basis of the packet numbers at- 
tached to the packets P^^, Pig Pij - Py- More specif- 
ically, when the packet numbers are serial numbers, the 
packet disassembler 1024 checks whether the packet 
numbers are all present from 1 to (Ixj). 
[0277] If all packets P are not present In the step 
S1 202, the packet disassembler 1 024 performs the step 
S1201 again, instead of moving to the step SI 203. As 
a result, the receiving portion 1022 eventually receives 
the lacking packets P. 

[0278] On the other hand, when the step S1202 
shows that all packets P are present, the packet disas- 
sembler 1 024 moves to the step 81 203. The packet dis- 
assembler 1024 disassembles the packets P^^, P^2 - 
P^j ... Py received In the step S1201 to restore the mas- 
ter data MD (step SI 203). The restored master data IV/ID 
is outputted to the file managing portion 1025, The file 
managing portion 1025 generates a cartographic f lie CF 
on the basis of the input master data MD. The generated 
cartography file CF is stored into the second storage 
device 1026 (step S1204). 

[0279] Afterthe step 81 204, the data processing por- 
tion 1023 checks whether there still remains any series 
of packets P to be received (step S 1 205). When packets 
P to be received still remain, it returns to the step S1201 
to continuously receive the packets P. When there Is no 
packet to be received, it ends the process of Fig.63. 
[0280] Fig.64 is a flowchart which shows the detailed 
procedure of the step SI 203 of Flg.63. Flg.65 shows the 
structure of data f onried during the process In which the 
cartography file CF is generated from the packets P^^, 
Pi2 •■• Pij ^ij- ^ ^^^^^ ^^^^ explanation above, 
at the time when the step S1203 of Fig.63 starts, the 
series of packets P^^. P12 - Pij - are all present as 
shown in Fig. 65(a) in the receiving portion 1022. The 
packet disassembler 1024 extracts packets P to be 
processed from among the packets Pit, P12 Pij • • P|j 
held in the receiving portion 1 022 (step SI 301 ). It is now 
assumed that the packet disassembler 1024 extracts 
the packets P^^, P12 • • 

[0281] Next, the packet disassembler 1 024 removes 
the packet number from each packet P extracted In the 
step SI 301. The packet disassembler 1024 unites the 
packets P together, from which the numbers have been 
removed, to restore one piece of segment data SD as 
shown in Fig. 65(b) (step S1302). Under the assumption 
above, the packets P^^. P12 Pij are combined togeth- 
er to restore the segment data SD^ . 
[0282] Each piece of segment data SD has the error 
correction code (or error detection code). After the step 
SI 302, the packet disassembler 1024 corrects en-ors 
possibly present in the restored segment data SD (with 
error correction code) by utilizing the error correction 
code (step SI 303). 

[0283] Next, the packet disassembler 1 024 removes 
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the error correction code from the segment data SD 
(with error correction code) and thereby restores the 
segment data SD (without error correction code) as 
shown in Fig.65(c) (step SI 304). The restored segment 

s data SD is held in the storage region in the packet dis- 
assembler 1 024. Underthe assumption above, the seg- 
ment data SD^ is error-corrected and then held in the 
storage region of the packet disassembler 1024. 
[0284] After the step SI 304, the packet disassembler 

10 1 024 checks whether packets P to be processed still re- 
main in the receiving portion 1022 (step 81305). When 
there are packets P to be processed, the packet disas- 
sembler 1024 returns to the step S1301; it can-les out 
the steps S1301 to 81304 to restore segment data SD 

15 from the packets P as shown in Fig.65(a) to (c). In this 
description, there are (ixj) packets P in the receiving 
portion 1 022 at the beginning of the process of Fig.64. 
Therefore the loop of the steps 81201 to SI 205 is re- 
peated i times. As a result the i pieces of segment data 

20 SD| to SD| are restored. 

[0285] When this loop has been repeated a required 
number of times, ho packets P to be processed are left 
in the receiving portion 1022. When the decision of the 
step 81 305 Is made in this condition, the packet disas- 

25 sembler 1 024 moves to the step S1 306. When all pack- 
ets P have been processed, the i pieces of segment data 
SDi to 8D| are being held in the packet disassembler 
1024. As stated above, the segment data SD.| to SD, 
each have a segment number. The packet disassembler 

30 1024 arranges the segment data SD^ to SD, according 
to the segment numbers, I.e. in the order of the serial 
segment numbers. Subsequently the segment numbers 
are removed from the segment data SD^ to SD,. The 
packet disassembler 1 024 thiBn unites together the seg- 

35 ment data SD^ to SD| from which the segment numbers 
have been removed. The master data MD is thus re- 
stored as shown in Fig.65(d) (step 81306). The restored 
master data MD is outputted to the file managing portion 
1025 (step 81307). 

40 [0288] Now, not only this map providing system but 
any communication system may encounter communica- 
tion troubles. Therefore the terminal device 102 cannot 
always correctly restore all pieces of segment data SD. 
Correctly restored segment data SD is segment data SD 

45 which Is Identical to that the center station 1 01 generat- 
ed. For example, suppose that the segment data SD2 
was not correctly restored and other segment data D^. 
SD3 to SDj were correctly restored. In such a case, the 
packet disassembler 1024 can correct thesegment data 

so 8D2 by using the error correction code attached to the 
segment data D^. SDsto SD}. 

[0287] In response to Input of the master data MD, the 

file managing portion 1025 starts the step SI 204. As al- 
ready stated, this step S1 104 Includes the process of 
55 generating a cartographic file CF from the master data 
MD and the process of storing the generated carto- 
graphic file CF in the second storage device 1 026. Fig. 
66 Is a flowchart showing the detailed procedure of the 
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step S1204of Fig.63, 

[0288] By the way, at the beginning of the step S1 204, 
the second storage device 1026 may already contain a 
cartographic file or cartographic files CF generated be- 
fore. Or it may contain no cartographic file CF. After re- 5 
ceiving the Input master data MD, the file managing por- 
tion 1025 checks whether any cartographic file CF is 
present in the second storage device 1026 (step 
S1401). When any cartographic file CF is present, the 
file managing portion 1025 moves to the step SI 404 
which will be described later. When no cartographic file 
CF is present, the file managing portion 1 025 generates 
a completely novel cartographic file CF on the basis of 
the present master data MD (step S1402). This carto- 
graphic file CF has the same data structure as the car- 
tographic file CF (see Figs.53(b) and 54). 
[0289] A method for generating the cartographic file 
CF is now described. As shown In Fig.62, the master 
data MD contains, in the data header DH, the carto- 
graphic file ID, the unit ID and the data size. This master 
data MD further contains, in the data portion, the file 
header FH and the entirety or part of a unit record UR. 
The file managing portion 1 025 extracts the file header 
FH from the master data MD. 

[0290] As already stated, the master data MD con- 
tains only one unit record UR. The file managing portion 
1025 generates a completely novel cartographic file CF 
in this time. Therefore the file managing portion 1025 
generates the initial value "1" as the number of units, 
NOU. Further, on the basis of the data size of the file 
header FH and the number of units NOU, the file man- 
aging portion 1025 extracts the offset value Xq.o to the 
unit record UR extracted this time. The unit manage- 
ment ihformatibh Mluivj^- is thus generated. 
[0291] The file managing portion 1025 has thus ex- 
tracted all information required to generate the com- 
pletely novel cartographic file CF. The file managing por- 
tion 1025 unites together the fiKe header FH, the unit 
management information Mlmsnj and the unit record UR 
extracted this time, in order to generate a cartographic 
file CF. This cartographic file CF has the data stmcture 
shown in Fig.67. The cartographic file CF thus generat- 
ed is stored in the second storage device 1026 (step 
SI 403). 

[0292] Next, when a cartographic file or cartographic 
files CF are found in the step 81401 , the process is per- 
fomried as shown below. The step SI 404 is carried out 
in this case. The file managing portion 1 025 extracts the 
file ID from the master data MD provided as the present 
input. As already stated, the file ID specifies which car- 
tographic file CF the unit record UR in the master data 
MD belonged to. As described referring to Fig.61, this 
file ID was generated by the packet assembler 1015 by 
using the file header FH of the cartographic file CF. 
[0293] The file managing portion 1025 also extracts 
the file header FH of each cartographic file CF in the 
second storage device 1026. The file header FH spec- 
ifies the area the cartographic file CF covers. As ex- 



plained about the step SI 402, the file header FH of the 
cartographic file CF was generated on the basis of the 
cartographic file CF managed in the center station 1 01 . 
[0294] Therefore if the file ID and the file header FH 
have identity, it shows that the present unit record UR 
is part of the cartographic file CF. The file managing por- 
tion 1025 therefore checks them for identity (step 
SI 404). 

[0295] When the step SI 404 shows absence of iden- 
tity, it meians that the cartographic file CF of which the 
input unit record UR Is a constituent element has not 
been generated before. In this case, the file managing 
portion 1025 pertorms the above-described steps 
S1402 and S1403. That is to say, a completely novel 
cartographic file CF is generated and stored in the sec- 
ond storage device 1 026. 

[0296] On the other hand, if the step S1404 decides 
that the file ID and the file header FH have Identity, It 
means that the cartographic file CF of which the input 
unit record UR is a constituent element has already, 
been generated. In this case, the file managing portion 
1025 selects this cartographic file CF as a target to be 
processed. The file managing portion 1 025 opens this 
target cartographic file CF (step S1405) and adds the 
Input unit record UR to the target cartographic file CF 
(step SI 406). That Is to say, in the step S1406, the input 
unit record UR and the cartographic file CF are com- 
bined together to generate an updated cartographb file 
CF. 

[0297] The step SI 406 is now described in greater de- 
tail. The file managing portion 1025 extracts the unit ID 
from the present master data MD. The unit ID extracted 
from the input master data MD is referred to as a first 
unit ID hereinafter. As explained refemng to Flg.62, the 
first unit ID specifies the unit record UR on which the 
present input master data MD Is based. The file manag- 
ing portion 1025 also extracts all unit IDs from the car- 
tographic file CF opened in the step SI 405. Each unit 
ID extracted from the cartographic file CF Is refenred to 
as a second unit ID hereinafter The second unit IDs may 
or may not contain one which agrees with the first unit 

ID: 

[0298] When the first unit ID does not agree with any 
of the second unit IDs, the file managing portion 1025 
extracts the unit record UR from the present Input mas- 
ter data MD and adds It to the currently opened carto- 
graphic file CF as shown in Fig.68 to update the carto- 
graphic file CF. 

[0299] When the first ID agree with one of the second 
unit IDs, it means that the present input unit record UR 
has been already provided to the terminal device 102 
from the center station 101. For example, in the step 
SI 204, the temninal device may already contain only the 
basic data (rough data) formed of the basic background 
data table BBD, the basic character/symbol data table 
BCD, and the highway network data table MND etc. in 
the unit record UR having the structure shown in Fig.54. 
In this case, the cartographic file CF cun'ently opened 
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has the structure as shown in Fig.69. In this case, as 
shown in Rg.70, the file managing portion 1025 adds 
the unit record UR extracted from the present Input mas- 
ter data to the unit record UR having the same unit ID 
In the currently opened cartographic file CF. Thus the 5 
cartographic file CF Is updated. 
[0300] Further, the file managing portion 1025 up- 
dates the unit management Infonmatlon MIunu accord- 
ing to the data size of the current input master data MD 
(step S1407). Next, the file managing portion 1025 
stores the updated cartographic file CF in the second 
storage device 1 026 (step SI 408). 
[0301] In this way, according to this map providing 
system, the first storage device 1013 contains the car- 
tographic file CF. The packet assembler 101 5 receives 
from the read control portion 1014 only partial map to 
be sent to the temnlnal device 1 02 and generates a se- 
ries of packets P representing the map. The series of 
packets P are transmitted on the wireless transmission 
path 1 03. What Is transmitted on the wireless transmis- 
sion path 103 is only the data which represents partial 
map. Therefore, in this map providing system, the 
amount of data sent on the wireless transmission path 
103 is reduced even if the cartographic file CF Itself Is 
large in size. This prevents the wireless transmission 
path 103 from being congested. 
[0302] The terminal device 1 02 thus sequentially re- 
ceives data which represents the partial map. However, 
at first, the terminal device 1 02 separately files the par- 
tial cartographic data. However, when an existing car- 
tographic file CF satisfies a given condition, the terminal 
device 102 adds the received partial cartographic data 
to that cartographic file CF and unites them together. 
Therefore, this map providing system can prevent gen- 
eration of a large number of files in the terminal device 
1 02. Hence vacant areas are less apt to form in the clus- 
ters In the second storage device 1 026. As a result, this 
map providing systienri can effectively use the storage 
region in the second storage device 1 026. 
[0303] Further, as shown in Fig. 52, a cartographic file 
CF is formed witlri a map a about a predetermined area 
which is sectioned Into a plurality of areas. I.e. units U. 
Dividing the map a Into units allows the read control por- 
tion 1 01 4 to easily read out required part of the map from 
the first storage device 1013.Thefonnatlon of units also 
allows the center station 1 01 to easily send out an opti- 
mum amount of data onto the wireless transmission 
path 1 03 so that the traffic on the wireless transmission 
path 1 03 will not be congested. 

[0304] When the center station 101 has transmitted a 
plurality of unit records UR, the temilnal device 1 02 may 
fail to receive some unit records UR because of a com- 
munication error. In such a case, the terminal device 1 02 
generates a cartographic file CF by using the success- 
fully received unit records UR. The terminal device 1 02 
can perfomn various operations on the basis of the gen- 
erated cartographic file CF. That is to say, even if some 
of the unit records UR sent from the center station 1 01 



are lacking, the lack does not affect other unit records 
received at the temiinai device 102. Dividing the map 
Into units provides this effect, too. 
[0305] Furthermore, in the unit record UR, the basic 
cartographic data (rough data) and detailed cartograph- 
ic data are described In a plurality of independent tables. 
Therefore the Individual tables can be used independ- 
ently even though they are stored In one unit record UR. 
That is to say, for example, when providing a map to the 
terminal device 1 02, the center station 1 01 can send ba- 
sic data (rough data) alone or detailed data alone, or 
both In combination. This allows the center station 101 
to provide a map according to the condition or purpose 
of the terminal device 1 02. 

[0306] For example, when the terminal device 1 02 de- 
sires to quickly receive a wide-area map rather than a 
detailed map, the center station 101 can preferentially 
send basic data (rough data) only. Further, the center 
station 2 can send the detailed data after the terminal 
device 102 has completely received the basic data 
(rough data). This allows the terminal device 1 02 to use 
the basic data (rough data) and the detailed data in com- 
bination. 

[0307] As already stated, mobile communication de- 
vices can be used as the transmitting portion 1016 and 
the receiving portion 1022. In this case, the bidirectional 
communication between the center station 101 and the 
terminal device 102 can be easily realized so that the 
terminal device 102 can Inform the center station 101 , 
in real time, of the desired type of the map (information 
showing whether it desires rough data or detailed data). 
[0308] Alternatively, a broadcasting device for ground 
wave digital broadcast etc. and a device receiving the 
broadcast can be used as the transmitting portion 1016 
and the receiving portion 1022. In this case, the center 
station 1 01 can control the times at which the basic data 
(rough data) and the detailed data are received and the 
map areas which can be received through these data 
by assigning different channels to the basic data (rough 
data) and the detailed data. 

[0309] In the embodiment described above, the file 
header FH of the cartographic file CF in the first storage 
device 1013 Is directly used as the file header FH of the 
cartographic file CF in the second storage device 1026. 
That Is to say, the two cartographic files CF cover the 
same area. However, the center station 101 and the ter- 
minal device 102 usually have different processing ca- 
pabilities. For example, the storage capacity of the sec- 
ond storage device 1 026 is usually smaller than that of 
the first storage device 1 013: Hence, the terminal device 
102 may generate a cartographic file CF which covers 
a smaller area than the map area represented by the 
cartographic file CF. That is to say, the terminal device 
1 02 may independently define the area the cartographic 
file CF covers. 

[0310] The second embodiment has explained a car 
navigation system as an example of the terminal device 
102. However, this embodiment can be applied also to 
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devices in which a database of the cartographic files CF 
is generated in a personai computer and the personal 
computer displays map or performs route search. That 
is to say, the technical field of the invention is not limited 
to the mobile terminal devices but can be applied also 
to stationary terminal devices. 

[0311] In a stationary terminal device, the communi- 
cation networic 1 03 is not necessarily a wireless trans- 
mission path but it can be wired. 

INDUSTRIAL APPLICABILITY 

[0312] The present invention relates to temnlnal de- 
vices, and the present Invention is suitable for a temnina! 
device which receives a cartographic file and stores it 
in a storage device in a system in which a server con- 
nected to the Internet, a broadcasting station, etc. sends 
cartographic files which contain digital data generated 
about individual units defined by dividing a map into a 
plurality of areas. 



Claims 

1. A terminal device for reading a cartographic file 
from a storage device in which cartographic files are 
stored as digital data generated about individual 
units defined by dividing a map into a plurality of 
areas, 

each said unit containing a road networl< repre- 
sented by nodes and llnlcs, each said carto- 
graphic file comprising node records generated 
for respective nodes and link records generat- 
ed for respective linl<s, 

said node records each containing infonnation 
about a non-neighboring node representing an 
intersection on said road network or infomnatlon 
about a neighboring node defining a connection 
of roads between its unit and another unit ad- 
joining said unit, 

said infomnation about said neighboring node 
being coordinate infomriation about said neigh- 
boring node, 

said terminal device comprising: 

an input device responsive to an operation 
by a user, for generating infomriation spec- 
ifying a map area; 

a data processing portion for specifying a 
record region where a necessary carto- 
graphic file is stored on the basis of the In- 
fonmation generated by said input device; 
and 

a read control portion for reading the car- 
tographic file from said storage device on 
the basis of the record region specified by 
said data processing portion, and 



wherein said data processing portion per- 
forms a given process by using the node 
records and the link records recorded in the 
cartographic file read by said read control 

s portion^ 

wherein said data processing portion trac- 
es a connection from a road in one unit to 
a road in another, neighboring unit on the 
basis of the coordinate information about 

10 the neighboring nodes of said one unit and 

said neighboring another unit. 

2. The terminal device according to claim 1 , wherein 
each said link record contains attribute iriformation 

IS which shows an attribute of the road represented 
by said link, and 

said data processing portion traces the con- 
nection from the road In said one unit to the road In 
said neighboring another unit also on the basis of 

^ the attribute infonnation about the links connected 
to the neighboring nodes of said one unit and said 
neighboring another unit. 

3. The terminal device according to claim 1 , wherein 
25 said node records whtoh contain the information 

about said neighboring nodes are successively re- 
corded in each said cartographic file. 

4. The terminal device according to claim 3, wherein 
30 said data processing portion traces the connection 

from the road In said one unit to the road In said 
neighboring another unit by searching only the node 
records which contain the information about the 
neighboring nodes in the cartographic file repre- 
ss senting said neighboring another unit 

5. The terminal device according to claim 1 , wherein 
in each said cartographic file, said node records 
which contain the Information about said neighbor- 

40 ing nodes are successively recorded In an ascend- 
ing or descending order of the coordinates of said 
neighboring nodes. 

6. The terminal device according to claim 5, wherein 
45 said data processing portion traces the connection 

from the road In said one unit to the road in said 
neighboring anpther unit by searching only the node 
records which contain the information about the 
neighboring nodes in the cartographic file repre- 
50 senting said neighboring another unit. 

7. The terminal device according to claim 1 , wherein 
in each said cartography file, said node records 
which contain the information about said neighbor- 
's ing nodes are successively recorded In an order In 

which said neighboring nodes follow one after an- 
other in one direction along the boundary of said 
unit. 
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8. The terminal device according to claim 7, wherein 
when said data processing portion traces the con- 
nection from the road in said one unit to the road in 
said neighboring another unit, said data processing 
portion searches, in the cartographic file represent- 
ing said neighboring another unit, only the node 
records which contain the infomnation about the 
neighboring nodes which are located on the bound- 
ary between said neighboring another unit and said 
one unit, in an order reverse to the order In which 
said node records of said one unit are recorded. 

9. The terminal device according to claim 3. wherein 
said units are fomried by dividing the map into po- 
lygonal areas, and 

In each said cartographic file, the node 
records which contain the Infomnation about the 
neighboring nodes located on each side of said unit 
are successively recorded. 

10. The terminal device according to claim 9, wherein 
said data processing portion traces the connection 
from the road in said one unit to the road in said 
neighboring another unit by searching, in the carto- 
graphic file representing said neighboring another 
unit, only the node records which contain the infor- 
mation about the neighboring nodes which are lo- 
cated on a given side of said neighboring unit, 

wherein said given side of said neighboring 
unit adjoins the side of said one unit to which the 
neighboring nodes belong. 

11. The temninal device according to claim 9, wherein 
the node records which contain the Infomnation 
about the neighboring nodes located on each side 
of said unit are recorded In an ascending or de- 
scending order of the coordinate information about 
said neighboring nodes. 



each said cartographic file stored in said stor- 
age device being provided with a file name 
uniquely corresponding to the map area repre- 
sented by itself, and 
5 said terminal device comprising: 

an input device responsive to an operation 
by a user, for generating information spec- 
ifying a map area; 
10 a data processing portion for specifying a 

record region where a necessary carto- 
graphic file is recorded on the basis of the 
infomnation generated by said Input device; 
and 

IS a read control portion for reading the car- 

tographic file from said storagie device on 
the basis of the record region specified by 
said data processing portion. 

20 14. The terminal device according to claim 13, 

wherein each said unit contains a road network 
represented by nodes and links, and ^ach said 
cartographic file comprises node records gen- 

25 erated for respective nodes and link records 

generated for respective links, 
and wherein said data processing portion per- 
forms a process of searching for a route by us- 
ing the node records and the linic records re- 

30 corded in the cartographic file which said read 

control portion has read this time, and 
when the route search ends in the area which 
the cartographic file read in this time repre- 
sents, said data processing portion calculates 

35 a map area required for a furtlner route search 

and specifies a record region where a carto- 
graphic file to be read next is stored on the ba- 
sis of the calculated map area. 



12. The terminal device according to claim 1 1 . wherein 
when said data processing portion traces the con- 
nection from the road in said one unit to the road in 
said neighboring another unit, said data processing 
portion searches, in the cartographic file represent- 
ing said neighboring another unit, only the node 
records which contain the Irifomnation about the 
neighboring nodes located on a given side of said 
neighboring unit, in the order in which said node 
records are recorded, 

wherein said given side of said neighboring 
unit adjoins the side of said one unit to which the 
neighboring nodes belong. 

13. A temninal device for reading a cartographic file 
from a storage device in which cartographic files are 
stored as digital data generated for individual units 
fomned by dividing a map into a plurality of areas, 



40 15. A terrninal device for reading a cartographic file 
from a storage device in which cartographic files are 
stored as digital data generated for individual units 
formed by dividing a map into a plurality of areas. 



45 Wherein each said unit contains a background 

which Is divided into objects each capable of 
being drawn with one stroke, said plurality of 
objects being grouped so that ones having the 
same attribute are contained in the same 

so group, 

said cartographic file containing background 
records In which information about the objects 
is recorded for each said group, 
said terminal device comprising: 

55 

an input device responsive to an operation 
by a user, for generating information spec- 
ifying a map area; 
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a data processing portion for specifying a 
record region where a necessary carto- 
graphic file is stored on the basis of the In- 
fonmatlon generated by said input device; 
a read control portion for reading the car- 
tographic file from said storage device on 
the basis of the record region specified by 
said data processing portion; and 
an output device, and 
wherein sald'data processing portion caus- 
es said output device to display the back- 
ground on the basis of the background 
records contained In the cartographic file 
read by said read control portion. 

16. The temninat device according to dalm 15, 

wherein each said object comprises element 
points representing a shape, and 
each said background record contains coordi- 
nate values of the element points of each said 
object^ said coordinate values being arranged 
In the order in which the element points are 
traced in the one stroke, 
and wherein the coordinate values of said ele- 
ment points are each represented by an abso- 
lute coordinate value based on an origin In said 
unit or by a relative coordinate value with re- 
spect to the coordinate value of another ele- 
ment point. 

1 7. The temninai devk^e according to claim 1 5, wherein, 
In each said object, the element point which corre- 

.. spends to a pen-down position is represented by 
the relative coordinate value when a given condition 
is satisfied. 

18. The tenrnlnal device according to claim 1 7, wherein 
said given condition is satisfied when the distance 
between the pen-down position and the pen-up po- 
sition immediately before is equal to or smaller than 
a given value. 

19. The temninai device according to claim 1 7, wherein 
said given condition is satisfied when the relative 
coordinate value of the element point correspond- 
ing to the pen-down position can be represented in 
a predetermined or smaller number of bits. 

20. The temninai device according to claim 15, wherein 
In each said object, the element points are each rep- 
resented by a direct coordinate value when a given 
condition is satisfied. 

21 . The temninai device according to claim 1 9, wherein 
said given condition is satisfied when the distance 
between an element point and the element point im- 
mediately before is equal to or larger than a given 



value. 

22. The terminal device according to claim 1 9, wherein 
said given condition is satisfied when thecoordlnate 

5 value of the element point represented by the rela- 
tive coordinate value exceeds a predetennlned 
number of bits. 

23. A recording medium In which cartographic files are 
recorded as digital data generated for individual 
units formed by dividing a map into a plurality of ar- 
eas, said cartographic files having a predetermined 
data structure for process perfonned by a computer 
device, 

said recording medium comprising: 

node records generated for respective nodes 
which fonm a road network in the unit In each 
said cartographic file; and 
link records generated for respective links 
which form the road network in the unit In each 
said cartographic file; 

said node records each containing information 
about a non-neighboring node which repre- 
sents an intersection on said road network, or 
coordinate information showing coordinates of 
a neighboring node which defines a connection 
of roads between a unit and a unit adjoining 
said unit, 

wherein said recording medium allows said 
computer device to execute the process com- 
prising the steps of: 

generating area information specifying a 
map area in response to an operation by a 
user, 

specifying a record region where a re- 
quired cartographic file Is recorded on the 
basis of the generated area information, 
reading the cartographic file on the basis 
of the specified record i^egion, and 
while executing a process of searching for 
a route by using the node records and the 
link records recorded in the read carto- 
graphic file, tracing a connection from a 
road in one unit to a road in another, neigh- 
boring unit on the basis of the coordinate 
Inf omnation about the neighboring nodes of 
said one unit and said neighboring another 
unit. 

24. The recording medium which contains the carto- 
graphs files according to claim 23, 

wherein each said link record contains attribute 
infomnatlon which shows an attribute of the 
road represented by said link, and 
while executing said process of searching for a 
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route, said computer device traces the connec- 
tion from tine road in said one unit to tlie road 
In said neighboring another unit also on the ba- 
sis of the attribute Infonrtation about the links 
connected to the neighboring nodes of said one 
unit and said neighboring another unit. 

25. The recording medium which contains the carto- 
graphic files according to claim 23, wherein said 
node records which contain the information about 
said neighboring nodes are successively recorded. 

26. The recording medium which contains the carto- 
graphic files according to claim 23, wherein said 
node records which contain the infonrjation about 
said neighboring nodes are successively recorded 
In an ascending or descending order of the coordi- 
nates of said neighboring nodes. 

27. The recording medium which contains the carto- 
graphic files according to claim 23, wherein said 
node records which contain the information about 
said neighboring nodes are successively recorded 
in an order in which said neighboring nodes follow 
one after another In one direction along the bound- 
ary of said unit. 

28. A recording medium in which predetermined data 
is recorded for process performed by a computer 
device, 

a recording medium In which cartographic files are 
recorded as digital data generated for Individual 
units formed by dividing a map into a plurality of ar- 
eas, having a structure, said recording medium 
comprising: 

the cartographic files as digital data generated 
for the individual units fomned by dividing the 
map into a plurality of areas, and 
management infonnation for managing record 
regions where said cartographic files are re- 
corded, where said cartographic files are pro- 
vided with names represented In a tree struc- 
ture, 

wherein said recording medium allows said 
computer device to execute the process conn- 
prlsirig the steps of: 

when area infonnation specifying a map ar- 
ea is entered from outside, specifying the 
nahie of a necessary cartographic file on 
the basis of the input area information; and 
reading the cartographic file from the 
record region uniquely corresponding to 
the name of the specified cartographic file 
by referring to said management Infonma- 
tion. 



29. A recording medium In which cartographic files are 
recorded as digital data generated for individual 
units fomned by dividing a map into a plurality of ar- 
eas, said cartographic files having a predetemiined 

5 data stmcture for process perfomned by a computer 
device, 

each said unit containing backgrounds, each 
said background being divided Into objects 
10 each capable of being drawn with one stroke, 

wherein said recording medium contains, 
infonnation which show attributes of the back- 
grounds, and 

object records which contain Information re- 

15 quired to draw said objects, 

wherein said infonnation showing the attributes 
of said backgrounds and said object records of 
the objects are successively recorded so that 
the plurality of objects are grouped according 

20 to their respective attributes, 

and wherein said recording medium allows said 
computer devbe to draw a map on the basis of 
said attribute information about said back- 
grounds and said object records contained In 

25 said cartographic file. 

30. The recording mediurh whk;h contains the carto- 
graphic files according to claim 29, wherein each 
said object comprises element points representing 

30 shape of said object, and 

each said object record contains coordinate 
values of the element points of Its said object, 
said coordinate values being arranged In an or- 
35 der in which the element points are traced in 

the one stroke, 

and wherein the coordinate values of said ele- 
ment points are each represented by an abso- 
lute coordinate value based on an origin in said 
40 unit or by a relative coordinate value with re- 

spect to the coordinate value of another ele- 
ment point. 

31. The recording medium which contains the carto- 
45 graphic files according to claim 29, wherein In each 

said object, the element point which corresponds to 
a pen-down position is represented by the relative 
coordinate value when a given condition is satisfied. 

50 32. The temnlnal device according to claim 29, wherein 
in each said object, the element points are each rep- 
resented by a direct coordinate value when a given 
condition Is satisfied. 

55 33. A tennlnal device for reading a cartographic file 
from a storage device in which cartographic files are 
stored as digital data generated for individual units 
formed by dividing a plurality of nriaps on different 
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scales each into a plurality of areas, 

said plurality of cartographic files having a hi- 
erarchical structure based on said scales, each 
said unit containing a road network represented 
by nodes and links, each said cartographic file 
at least containing node records which are gen- 
erated for respective nodes and contain coor- 
dinate infomiation about said nodes, and link 
records which are generated for respective 
links, 

in each saidcartographicfile, said node records 
being recorded In an ascending or descending 
order of the coordinate infomnatlon about said 
nodes, 

said terminal device comprising: 

an input device for generating Information 
specifying a map area; 
a data processing portion for specifying a 
record region whiere a necessary carto- 
graphic file is recorded, on the basis of the 
information generated by said input device; 
and 

a read control portion for reading the car- 
tographic file from said storage device on 
the basis of the record region specified by 
said data processing portion, 
wherein said data processing portion 
searches for a node in a unit at a higher 
level which corresponds to a node con- 
tained in a unit at a lower level on the basis 
of the coordinate information recorded In 
the cartographic file read by said read con- 
trol portion. 

34. The temninal device according to claim 33, wherein 
said data processing portion searches for the node 
in the unit at the higher level corresponding to the 
node contained in the unit at the lower level also on 
the basis of the order in which said node records 
are recorded. 

35. A system in which a center station provides a car- 
tographic file to a terminal device through a trans- 
mission path, 

wherein said center station comprises, 
a first storage device containing the carto- 
graphic file, said cartographic file representing 
a map of a predetenmined area, 
a read control portion for reading, as carto- 
graphic data, part or all of the cartographic file 
from said first storage device, 
a packet assembler for assembling packets in 
a form appropriate for said transmission path 
by using the cartographic data read by said 
read control portion, and 



a transmitting portion for transmitting the pack- 
ets assembled by said packet assembler to 
said temninal device through said transmission 
path, 

s and wherein said terminal device comprises, 

a receiving portion for receiving the packets 
transmitted by said transmitting portion through 
said transmission path, 

a data processing portion for disassembling the 
10 packets received by said receiving portion and 

restoring the cartographic data, and 
a second storage device having an internal 
storage medium for storing a cartographic file, 
wherein when a cartographic file related to the 
IS cartographic data restored this time is already 

stored in said second storage device, said data 
processing portion reads that cartographic file 
from said second storage device, 
and said data processing portion performs the 
so process of adding the restored cartographic da- 

ta to the second cartographic file thus read and 
stonng said cartographic file in said second 
storage device. 

25 36. The map providing system according to claim 36, 
wherein said data processing portion generates a 
plurality of cartographic files when necessary. 

37. The map providing system according to claim 35, 
30 wherein said cartographic file comprises a plurality 
of units in which said map of predetermined area is 
sectioned into a plurality of areas and management 
information for managing each said unit, 

35 and wherein in said center station, 

said read control portion reads the cartographic 
data, unit by unit, from said cartographic file 
stored in said first storage device, and 
said packet assembler assembles the packets 
40 by using the unit read by said read control por- 

tion, a file ID specifying the cartographic file, a 
unit ID specifying said unit, and data size of said 
unit. 

45 38. The map providing system according to claim 37, 
wherein said data processing portion further ex- 
tracts the file ID, the unit ID and the data size from 
the packets received at said receiving portion, and 
said data processing portion disassembles 

50 the packets received at said receiving portion and 
restores the cartographic data by using the extract- 
ed file ID, unit ID and data size. 

39. The map providing system according to claim 35, 
55 wherein said cartographic file further comprises ba- 
sic data schematically showing said predetermined 
area and detailed data showing said area in detail, 
and 
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said basic data and said detailed data have 
data structures which can be separated from each 
other. 

40. The map providing system according to claim 39, 

wherein said basic data further comprises basic 
background data representing background of 
said map, basic character/symbol data sche- 
matically representing a character and a sym- 
bol to be displayed in said map, and major road 
network data representing a major road net- 
work existing in said map, and 
said detailed data further comprises detailed 
background data representing details of the 
background of said map, detailed character/ 
symbol data representing a detailed character 
and symbol to be displayed In said map, and 
minor road network data representing a minor 
road network existing in said map, 
and wherein said detailed background data, 
said detailed character/symbol data and said 
minor road network data are formed as differ- 
ential data of said basic background data, sard 
detailed character/symbol data and said minor 
road network data, and said basic data and said 
detailed data are combined to represent a rel- 
atively detailed map. 

41. The map providing system according to claim 39, 
wherein said read control portion further reads, as 
the cartographic data, only the basic data contained 
In the cartographic file stored |n said first storage 

device. 

42. The map providing system according to claim 41, 
wherein said read control portion further reads, as 
the cartographic data, only the detailed data con- 
tained In the cartographic file stored in said storage 
device. 

43. The map providing system according to claim 39, 
wherein said read control portion further reads, as 
the cartographic data, the basic data and the de- 
tailed data contained in the cartographic file stored 
In said first storage device. 

44. The map providing system according to claim 41 , 
wherein said data processing portion further disas- 
sembles the packets received by said receiving por- 
tion to restore the basic data. 

45. The map providing system according to claim 44, 
wherein said read control portion in said center sta- 
tion further reads, as the cartographic data, only the 
detailed data contained in the cartographic file 
stored in said first storage device, and 

said data processing portion in said mobile 



station further assembles the packets received by 
said receiving portion to restore the detailed data. 

46. The map providing system according to claim 43, 
5 wherein said data processing portion further disas- 
sembles the packets received at said receiving por- 
tion to restore the basic data and the detailed data. 
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Par. No. 19; Fig. 2 (Patnily: none) 



JP, 63-086074, A (Hitachi, Ltd.), 
16 April, 1988 (16.04.88), 
page3/ lower left column, lines 1-16; 
(Family: none) 



iPig. 5 



EP, 807803, A2 (MATSUSHITA ELECTRIC IND CO LTD), 
19 November, 1997 (19,11.97), 
Full text 



1-12,23-27 



1-12,23-27 



13-14,28, 
33-34 



13-14,28 



15-22,29-32 



1^ Further documents are listed in the continuation of Box C. Q See patent family annex. 



* Special categories of cited documents: 

"A" document defining the general state of the art which b not 

considered to beef particular relevance 
"ET earlier document but published on or after the fanemational filing 

date 

**L" document which may throw doubts on priority claim(s) or which is 
cited to establish the pid>Ucailon date of another eitanon or other 
special reason (as specified) 

"0^ (tocument leferrmg 16 ah oral disclosure, use, exhibition or other 
means 

"P** documtnt published prior to the inlcmationil filing date but Inter 

than the priority date claimed 



"T* later document pub lished a fter the international filti^g date or 
priority dais and not in conflict with the application but cited to 
imderstand the principle or theory underlying the invention 

"X" document of particular rdcvance; the claimed invention caimot be 
considered novel or cannot be considend to involve an inventive 
step when the doctnncat is taken alone 

"Y" documem of pardcular relevance; the claimed Invention cannot be 
considered to involve on inventive step when the documem is 
combined with one or more other such documents, such 
combination being obvious to a person tkiHed in the art 

" &" document member of the same patent family 



Date of the actual completion of the intematioiial search 
07 January. 2000 (07.01.00) 



Date of mailing of the intereational search report 
25 January, 2000 (25.01.00) 



Name and mailing address of the ISA/ 

Japanese Patent Office 

Facsimile Na 



Authorized oHicer 
Telqihone No. 



Fonn PCT/ISA/210 (second sheet) (July 1992) 



115 



BNSOOCIO: <EP 1134e74A1J_> 



EP 1 134 674 A1 



INTERNATIONAL SEARCH REPORT 


Intemational application No. 

PCT/JP99/06543 


C (Continuation). DOCUMENTS CONSIDERED TO BE RELEVANT 


Caiegoiy* 


Citation of document^ with indication, where appropriate, of the relevant passages 


Relevant to claim No.- 


A 
A 

A 


& JP, 10-049047, A 

Full text 

& KR, 97076413, A 

JP, 07-103775, A (Matsushita Electric Ind. Co., Ltd.), 
18 April, 1995 (18.04.95), 
Fig. 3 (Family: none) 

EP, 875878, A2 (MATSUSHITA ELECTRIC IND CO LTD) , 
04 Koveniber, 1998 (04.11.98), 
Full text 

6 JP, 10-300499, A 
Full text 

JP, 10-255022, A (Sony Corporation) , 
25 September, 1998 (25.09.98) « 
Par. NO. 36 (Family: none) 


15-22,29-32 
35-46 

35-46 



Fomi PCT/ISAy2I0 (continuation of second sheet) (July 1992) 



116 



BNSDCCID: <EP 1134e74A1J_> 



EP1 134 674 A1 



INTERNATIONAL SEARCH REPORT 



International application No. 

PCT/JP99/06543 



Box I Observations where certain claims were found unsearchable (Continuation of item 1 of first sheet) 



This international search report has not been esiaolished in respect of certain claims under Article 1 7(2Xa) for the following reasons: 
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because they relate to subject matter not required to be searched by this Authority, namely: 



2. Q Claims Nos.: 

because th^ relate to parts of the international application that do not comply with the prescribed requirements to such an 
extent that no meantngfiil intemationa) search can be carried out, specifically: 



3. □ Claims Nos.: 

because they are dependent claims and are not drafted in accordance with the second and third sentences of Rule 6d4<a). 



Box II Observations where unity of invention Is lacking (Continuation of Item 2 of first sheet) 



This International Searching Authoricy ibund multiple inventions in this international application, as follows: 

The technical feature of the inventions of claims 1 to 12, 23 to 27 Is an idea 
of tracing the connect ion of roads by referring tonode records 
and link records. 

The technical feature of the inventions of claitns 13, 14, 28, 33, 34 is an 

idea of naming a file of a map. 
The technical feature of the inventions of claims 15 to 22, 29 to 32 is an 

idea of processing data in units of an object written with 

a single stroke. 

The technical features of the inventions of claims 35 to 46 axe an idea o£ 

processing a packet and an idea of storing a map file. 
Therefore, the number of groups of inventions of the international applicatiozr 

is four. 

L Q As all required additional search fees were timely paid by the applicant, this intemaiional search repon covers all searchable 
claims. 

2. IS A s all searchable claims could be searched wiihom efXbrt justifying an additional fee, this Authority did not invite paymem 

of any additional fee. 

3. Q ^ o'^'y some of the required additional search fees were timely paid by the applicant, this iatemational search report covers 
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